November 2007 - xwiki-devs@xwiki.org

[xwiki-devs] [ANN] XEclipse 1.0.1 Released
by Fabio Mancinelli 30 Nov '07

30 Nov '07

The XWiki development team is pleased to announce the release of XEclipse 1.0.1 You can find it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiEclipse XEclipse is an Eclipse plug-in that allows the user to interact with an XWiki server directly from within the Eclipse IDE. It comes in two flavors: as an Eclipse plugin that can be directly integrated in the Eclipse IDE or as a standalone RCP application. This release is mostly a maintenance release that fixes some serious bugs that prevented XEclipse version 1.0 to work correctly. Main changes from 1.0: * Solved XMLRPC issues when connecting to XWiki version 1.2 * Solved problems in XWiki Explorer structure visualization. * Added some minor user interface improvements (e.g., page loading progress bars). Thanks -The XWiki dev team

1 0

[xwiki-devs] [VOTE] Release XWiki Platform, Panels Application and XWiki Enterprise 1.2 RC1
by Sergiu Dumitriu 30 Nov '07

30 Nov '07

Hi, As previously proposed, today (Friday 30th) is the planned day for the first 1.2 Release Candidate. There are still a few issues remaining http://jira.xwiki.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10010… which I'd like to see fixed before noon (CET), when I'll start the release process. There will probably be another RC shortly, as there are a few more tasks that should be fixed for improving the stability of the 1.2 version of XE, but there should be a final 1.2 before Javapolis. Thanks, Sergiu and my +1

5 4

[xwiki-devs] [VOTE] Create a branch for the remaining 1.2 releases and use the trunk for 1.3 for Platform and XE
by Sergiu Dumitriu 30 Nov '07

30 Nov '07

Hi, I'd like to move the current trunk (1.2-SNAPSHOT) to a branch right after the release planned for today, given the fact that after the first RC no new features or major changes in the code can be committed. The only projects that need to be branched are platform-core, platform-web and products-enterprise, as the others will not see major modifications in less than two weeks. However, if someone does need to commit new code in a dependency for XE/platform, we can create a branch on the fly. Thanks, Sergiu and my +1

4 3

[xwiki-devs] Do we want the simple/advanced mode feature to be a core feature?
by Vincent Massol 29 Nov '07

29 Nov '07

If the answer is yes, then I propose that we modify the XWiki.getUserClass() method to create a XWiki.XWikiUsers class that has the "usertype" property by default. I think the notion of simple/advanced user could be one that is generic enough to be a core feature. I'm curious to know what you think. Thanks -Vincent

2 1

[xwiki-devs] [VOTE] Anca Luca as a XWatch committer
by Jerome Velociter 28 Nov '07

28 Nov '07

Dear XWikiers, I'd like to propose voting Anca Luca as a XWatch committer. Anca has submitted several good patches for XWiki Watch. (see http://tinyurl.com/2x3psb) She writes clean code and shows a strong focus on design and separation of concerns. I propose she now commit her own patches on XWatch! Here's my +1 for Anca. Note: For full disclosure, Anca is working for XPertNet, the company behind the creation of XWiki. FWIW, out of the 26 committers (http://www.xwiki.org/xwiki/bin/view/Community/HallOfFame) 9 are working for XPertNet. Note that the XWiki project is driven as a meritocratic project (trying to follow the Apache rules as much as possible) and thus anyone can become a committer (see http://www.xwiki.org/xwiki/bin/view/Community/Committership) The more the merrier! Regards, Jérôme.

7 6

[xwiki-devs] [Proposal] Add .xml extension to exported documents files names.
by Thomas Mortagne 28 Nov '07

28 Nov '07

Hi all, Having xwiki document with no extension in the files names is a real mess for subversion and IDEs like Eclipse and IntelliJ IDEA and it will also be very useful in any editor that takes extension to determine the content or simply for most OS Explorers/Finders. As the XWiki maven xar plugin now support files with any name when creating the xar package (see http://jira.xwiki.org/jira/browse/XTOOLS-19) I propose to add .xml extension to exported document files names. Import document with any names is already supported by xwiki core importer plugin since at least svn1387 (October 2006) and I think since it's creation so it seems it will not break older version import. -- Thomas Mortagne

4 3

[xwiki-devs] What remains to release XE 1.2RC1
by Vincent Massol 27 Nov '07

27 Nov '07

Hi, Here's my list of what remains to be done to release XE 1.2RC1: * fix the MINOR EDIT exception that happens from time to time on xwiki.org: http://jira.xwiki.org/jira/browse/XWIKI-1879 * continue looking at xwiki.org logs and fix exceptions that appear * commit the stats patch submitted by Marius http://jira.xwiki.org/jira/browse/XWIKI-1845 * fix the XHTML validation issues discovered by the build * test the stats feature on xwiki.org (enable stats with Raffaello and monitor xwiki.org's performances) * test the watchlist feature on xwiki.org (configure the smtp server with Raffaello and try the feature) If you know of other important issues for XE 1.2RC1 that cannot wait for later please let us know. Thanks -Vincent

4 5

Re: [xwiki-devs] [xwiki-notifications] r6086 - in xwiki-platform/xwiki-applications/trunk/s5: . wiki wiki/src
by Vincent Massol 27 Nov '07

27 Nov '07

Hi Sergiu, We need to discuss this since this is starting something new that we've never discussed. How do you plan to distribute the s5 application? I don't see how to do that with a web module or do you mean that this web module will generate a zip that the user will manually unzip in his xwiki webapp? Should we distribute 2 files (XAR+ZIP) or one file (a single zip containing both)? Also this raises the question of plugins which I've started to discuss some time ago: should they go in applications or stay in plugins/? Thanks -Vincent On Nov 26, 2007, at 6:59 PM, sdumitriu (SVN) wrote: > Author: sdumitriu > Date: 2007-11-26 18:59:12 +0100 (Mon, 26 Nov 2007) > New Revision: 6086 > > Added: > xwiki-platform/xwiki-applications/trunk/s5/wiki/ > xwiki-platform/xwiki-applications/trunk/s5/wiki/pom.xml > xwiki-platform/xwiki-applications/trunk/s5/wiki/src/ > xwiki-platform/xwiki-applications/trunk/s5/wiki/src/main/ > Removed: > xwiki-platform/xwiki-applications/trunk/s5/src/ > xwiki-platform/xwiki-applications/trunk/s5/wiki/src/main/ > Modified: > xwiki-platform/xwiki-applications/trunk/s5/pom.xml > Log: > Create a submodule for the wiki pages, as this application should > also contain velocity templates and skin files that will go in a web > module. > [snip]

2 1

[xwiki-devs] Velocity template for a default class sheet ?
by jvivien.m2 jvivien.m2 26 Nov '07

26 Nov '07

Hello, I was wondering about the code that is by default in a class sheet - when you create a class with the class wizard. The class sheet has code to display all properties of one object of the concerned class. To display each property, you use the display() method which accesses a property through its name. Now imagine you have a page with objects of different classes, and some of the classes have same-named attributes. The respective class sheets are all included in the page. Then the display() method, when used, will be confused. How about replacing the Velocity call $doc.display($prop.getName()) by this one : $doc.getObject("YourClassSpace.YourClass").get($prop.getName()) ? What do you think ? -- Jean-Vivien MAURICE Elève Ingénieur Informatique et Gestion, Polytech'Montpellier (ISIM) E-mail : jean.vivien.maurice(a)gmail.com Tél. : 0046 7 62 33 20 46 Skype : jean.vivien

1 0

[xwiki-devs] [VOTE] Suggestions for versions improvements
by Vincent Massol 26 Nov '07

26 Nov '07

Hi, Since we're nearing the final XE 1.2 release I'd like that we vote on each of the following: 1) Once Panels app 1.2 is released, separate the versioning of the Panels app from the versioning of XE/Platform, i.e. next version will be 1.3 without milestones. Same as for the other apps/plugins. 2) Create a branch now for XE/Platform/Panels 1.2RC1 so that work can start on trunk for Platform 1.3M1 and XE 1.3M1. 3) Don't do a XE/PF/Panels 1.1.3 release and instead move XEM and other products to XE/PF/Panels 1.2 final (since it's going to be released in less than a month). This will also allow to have only 2 branches to manage: the trunk and the branch from 2). This also means that we should probably release a XEM 1.0 quickly (that'll use PF 1.1.2) and start working on XEM 1.1 on trunk which will use PF 1.2. Here's my +1 to all 3 items above. Thanks -Vincent

6 8