xwiki-devs November 2007

xwiki-devs@xwiki.org

28 participants
64 discussions

[xwiki-devs] [ANN] XEclipse 1.0.1 Released

by Fabio Mancinelli

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

16 years, 9 months

[xwiki-devs] [VOTE] Release XWiki Platform, Panels Application and XWiki Enterprise 1.2 RC1

by Sergiu Dumitriu

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

16 years, 9 months

[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

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

16 years, 9 months

[xwiki-devs] Do we want the simple/advanced mode feature to be a core feature?

by Vincent Massol

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

16 years, 9 months

[xwiki-devs] [VOTE] Anca Luca as a XWatch committer

by Jerome Velociter

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.

16 years, 9 months

[xwiki-devs] [Proposal] Add .xml extension to exported documents files names.

by Thomas Mortagne

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

16 years, 9 months

[xwiki-devs] What remains to release XE 1.2RC1

by Vincent Massol

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

16 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r6086 - in xwiki-platform/xwiki-applications/trunk/s5: . wiki wiki/src

by Vincent Massol

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]

16 years, 9 months

[xwiki-devs] Velocity template for a default class sheet ?

by jvivien.m2 jvivien.m2

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

16 years, 9 months

[xwiki-devs] [VOTE] Suggestions for versions improvements

by Vincent Massol

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

16 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs November 2007