xwiki-devs October 2011

xwiki-devs@xwiki.org

29 participants
64 discussions

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 and XWiki Enterprise Manager 3.2 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Commons, XWiki Rendering, XWiki Platform, XWiki Enterprise and XWiki Enterprise Manager 3.2. Following the goals established for the 3.x cycle, XWiki Enterprise 3.2 pushes forward in the directions of the Application Within Minutes and Extension Manager features. The highlights of this release are: * many extension manager improvements * new implementation of the sheet system making it easier to bind sheets to objects without an explicit inclusion of the sheet in the document content * user dashboards giving each user the possibility to configure their own home page * introduction of wiki workspaces, as a more collaborative way of managing an XWiki virtual farm * improvements of search results scoring * storage improvements, bringing in numerous performance and compatibility improvements * conversion of the panels application to the XWiki 2.0+ syntax * easier activation and configuration of Google Analytics And on the developers' front: * CSRF prevention enabled by default * support for DocBook syntax * xwiki-commons and xwiki-rendering are now published on the central Maven2 repository * some major code cleanup due to the retirement of some very old plugins and the move of legacy/deprecated code into separate modules See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 11 months

[xwiki-devs] [VOTE] Move to Infinispan as default cache implementation

by Thomas Mortagne

Hi devs, I just finished and committed an Infinispan (http://www.jboss.org/infinispan) based cache API implementation. I would like to propose to move to it by default instead of the JBossCache one. Pros: * Infinispan is basically the new name of JBossCache starting with version 4 * as far as I can see the perf are a bit better especially in the creation of new cache which is important for the cache macro which potentially create lot's of caches WDYT ? here is my +1 -- Thomas Mortagne

12 years, 11 months

[xwiki-devs] [VOTE] Retire xwiki watch

by Vincent Massol

Hi Devs, We've not been touching XWiki Watch for a long time and there's now the XWiki Reader contribution. Here's what I propose to do: * Move watch code to xwiki-contrib * Move documentation found on watch.xwiki.org on an extension page on extensions.xwiki.org. * Mention on that page that a new project has started: XWiki Reader and point to it * Remove watch.xwiki.org * Update home page of xwiki.org to remove watch from there and from the forge page Here's my +1 (and I'm ok to do it with maybe the help of sergiu for the github move) Thanks -Vincent

12 years, 11 months

[xwiki-devs] [VOTE] Leave CSRF protection enabled by default in 3.2 final

by Alex Busenius

Hello devs, As you know, the 3.2 branch currently has CSRF protection enabled by default for testing purposes. The tests are working fine with it since a couple of months now, and there were only some non-critical bugs found and fixed during that time. The only currently unresolved problem I'm aware of right now is http://jira.xwiki.org/browse/XWIKI-6784 I have some quick test for it locally, but I had very little time recently to clean it up and commit. The 3.2-M* and 3.2-rc* releases have the CSRF protection enabled and have been tested on myxwiki.org without big problems. CSRF protection is important security improvement and we should encourage users to enable it. Nevertheless, enabling it by default is a potentially dangerous change, since it will expose problems with not-CSRF protection aware third party extensions after the update, and therefore needs to be voted about. Related bugs (fixed): http://jira.xwiki.org/browse/XWIKI-4873 http://jira.xwiki.org/browse/XWIKI-6773 Here is my +1 for leaving it enabled. WDYT? Thanks Alex

12 years, 11 months

[xwiki-devs] Fwd: [ANNOUNCEMENT] Apache Commons IO 2.1 Released

by Vincent Massol

See below Begin forwarded message: > From: Gary Gregory <ggregory(a)apache.org> > Subject: [ANNOUNCEMENT] Apache Commons IO 2.1 Released > Date: October 10, 2011 5:13:43 PM GMT+02:00 > To: announce(a)apache.org, dev(a)commons.apache.org, user(a)commons.apache.org > > The Commons IO team is pleased to announce the Commons IO 2.1 release! > > The Commons IO library contains utility classes, stream implementations, file filters, file comparators and endian classes. > > This is a drop-in replacement for 2.0.1. A list of the 7 new features, 1 change and 7 bug fixes in this release are found in the > release notes and below. > > https://commons.apache.org/io/changes-report.html#a2.1 > > For general information on Commons IO please visit the website: > > http://commons.apache.org/io/ > > The latest version may be downloaded from the following page: > > http://commons.apache.org/io/download_io.cgi > > Thanks again to all involved in the release, both Commons users and > Commons developers. > > = New features since 2.0.1 = > > o Use standard Maven directory layout Issue: IO-285. Thanks to ggregory. > o Add IOUtils API toString for URL and URI to get contents Issue: IO-284. Thanks to ggregory. Could be useful to replace our XWiki.getURLContent() implementation. Thanks -Vincent > o Add API FileUtils.copyFile(File input, OutputStream output) Issue: IO-282. Thanks to ggregory. > o FileAlterationObserver has no getter for FileFilter Issue: IO-262. > o Add FileUtils.getFile API with varargs parameter Issue: IO-261. > o Add new APPEND parameter for writing string into files Issue: IO-182. > o Add new read method "toByteArray" to handle InputStream with known size. Issue: IO-251. Thanks to Marco Albini. > > = Fixed Bugs since 2.0.1 = > > o Dubious use of mkdirs() return code Issue: IO-280. Thanks to sebb. > o ReaderInputStream enters infinite loop when it encounters an unmappable character Issue: IO-277. > o FileUtils.moveFile() JavaDoc should specify FileExistsException thrown Issue: IO-264. > o ClassLoaderObjectInputStream does not handle Proxy classes Issue: IO-260. > o Tailer returning partial lines when reaching EOF before EOL Issue: IO-274. Thanks to Frank Grimes. > o FileUtils.copyFile() throws IOException when copying large files to a shared directory (on Windows) Issue: IO-266. Thanks to Igor Smereka. > o FileSystemUtils.freeSpaceKb throws exception for Windows volumes with no visible files. > Improve coverage by also looking for hidden files. Issue: IO-263. Thanks to Gil Adam. > > = Changes since 2.0.1 = > > o FileAlterationMonitor.stop(boolean allowIntervalToFinish) Issue: IO-259. > > Gary, on behalf of the Apache Commons community > -- > E-Mail: garydgregory(a)gmail.com | ggregory(a)apache.org > JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 > Spring Batch in Action: http://bit.ly/bqpbCK > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory

12 years, 11 months

[xwiki-devs] [Announcement] XWiki Enterprise 3.2 Release Candidate 1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.2 Release Candidate 1. This is the first (and hopefully last) release candidate for the 3.2 series. Apart from a few minor bugfixes, this version brings the Workspace Manager as a standard feature of the platform, as an alternative way of using virtual wikis, compared to XEM. See http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise32RC1 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 11 months

[xwiki-devs] XEclipse RESTification

by Fabio Mancinelli

Hi everybody, I've just merged the work done by Jun Han in the master branch of the XEclipse repo (https://github.com/xwiki/xwiki-eclipse) Jun has worked during the summer for this GSoC project. Here it is a summary of what has been done, as summarized by Jun: Major work is listed below: 1. Implement an abstract storage layer independent of xmlrpc or rest backend 2. New storage implementation using the XWiki REST API 3. Multiwiki support in the navigator view (using the updated REST API storage) 4. Improve user interface and responsiveness 5. Use JSON library in local storage to replace XML 6. Add operations (add/delete/edit) of page, objects, attachments, class, revision, tag, translation, and comments supported by current REST API Fixed Issues include (not complete): 1. XWiki Eclipse XECLIPSE-154 Grab space operation fails on Spaces named in cyrillic 2. XWiki Eclipse XECLIPSE-137 Open version problem 3. XWiki Eclipse XECLIPSE-131 Error when clicking on a List type object field in the outline view 4. XWiki Eclipse XECLIPSE-41 Display references to document's attachments 5. XWiki Eclipse XECLIPSE-150 Move the build system to Tycho 6. XWiki Eclipse XECLIPSE-145 Maven-based build of XEclipse requires customization to work out of the box 7. XWiki Eclipse XECLIPSE-51 Eclipse update feature 8. XWiki Eclipse XECLIPSE-149 XEclipse does not start under Ubuntu 10.4 9. XWiki Eclipse XECLIPSE-133 XEclipse does not start on OSX if JDK 1.6 is selected 10. XWiki Eclipse XECLIPSE-94 When connecting to a multiwiki install, list all subwikis and ask to which one to connect to >From previous discussion, considering the big amount of new/improved features, we've decided to promote this new development line to 2.0.0-SNAPSHOT and deprecate the old 1.2 one. The idea is to fix the outstanding bugs in order to converge towards a 2.0.0-M1 and then 2.0.0 final. I'd like to thank Jun for his involvement and I hope that he will continue to help us making XEclipse improve. Thanks, Fabio

12 years, 11 months

[xwiki-devs] [Announcement] XWiki Enterprise 3.1.1 and XWiki Enterprise Manager 3.1.1 Released

by Sergiu Dumitriu

The XWiki development team is proud to announce the availability of XWiki Enterprise 3.1.1 and XWiki Enterprise Manager 3.1.1, bugfix releases on the 3.1.x stable branch. This is the first (and probably last) bugfix release for the 3.1 series. It contains only small bugfixes backported from the 3.2 branch, mainly around missing CSRF-prevention tokens, the extension manager, and build improvements. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise311 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 11 months

[xwiki-devs] [VOTE] Improving the migration manager to fix XWIKI-7006, XWIKI-1859, XWIKI-2075, XWIKI-2066

by Denis Gervalle

Hi devs, I need to do XWIKI-6990 (Reduce the likelihood of having same (hibernate) document id for different documents), but XWIKI-7006 (Accessing a store that is not migrated to the lastest data version should not be allowed) is blocking for this to be safely introduced. So I have refactored the migration code to better protect the database, I would like your vote to introduce this patch first, another vote will come for XWIKI-6990. The proposed commit is available at https://github.com/dgervalle/xwiki-platform/commit/f1fa1b1357d17c1ee4ed65eb… In summary, here is what it does: a) Refactor the old XWikiMigrationInterface and XWikiMigratorInterface into new DataMigrationManager and DataMigration interfaces b) Implement the DataMigrationManager and the DataMigration interfaces using components for the hibernate stores c) Remove the migration check from XWiki and put them in hibernate stores components, freeing this from XWiki. Since store still use the XWikiContext, I still use it, but from the execution context, no more passing it everywhere. d) Use a cache for DB version to not degrade performance e) Remove many call to schemaUpdate which require synchronization, executing only schema updates during data migrations. f) Remove some data migration like code from schemaUpdate, convert it to HQL (in place of native SQL :() and put them in an initial LegacyDataMigration, that migrate from version 0 to version 1 g) Fix empty/new database issue by considering a database without version AND without documents as a new database, and initialize it with the current schema and the latest version. h) Properly report migration failure and prevent access on failure i) Prevent access to any database not being properly migrated to the latest version by never providing a valid transaction for it. By the way, fix another (unnoticed ?) bug: if a throw occurs during database switching, a transaction could be return and used improperly (mixing data from different database). j) deprecate xwiki.store.hibernate.updateschema, but use "1".equals(config.getProperty("xwiki.store.migration", "0") && !"0".equals(config.getProperty("xwiki.store.hibernate.updateschema") to enable migrations k) Now xwiki.store.migration.databases=all, before it was xwiki only, which is not right IMO Currently, migration manager is injected in stores, using a hint, since the migration manager will be different depending on the store that keep the data version. The migration manager lookup the store by hint to retrieve the data version. The migration manager lookup data migrations using hint as well. Finally, data migrations lookup stores again using hint. Some improvements would be to allow multiple data versions (one per store hint), and mix data migration, since stores could be mixed, but this is out of my scope currently. To support injecting store by scope properly, there is another separate commit, available at https://github.com/dgervalle/xwiki-platform/commit/6a353d6d45bfb73789ed0693…, which replace the default unnamed stores, by "hibernate" named stores. Since store are still initialized at XWiki initialization, migration still occurs during first request to the system, but this is no more related to the migration system, which intercept the first database access, but this is related to this XWiki initialization only now. So XWIKI-2075 is fixed for me. I have already work hard to reach this state, there is still room for improvements, but I will not be able to afford much more time on this right now (at least without a sponsor :)). Please be fair in your remarks ;) Here is my +1. Currently the patch is done for 3.3, but if you think it could go in 3.2, I am +1. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 11 months

[xwiki-devs] [VOTE] Fixing cyclic dependency introduced by the workspace module

by Eduard Moraru

Hi devs, The workspace module has a maven artefact (workspace-template) that produces an enhanced (adds extra pages, set some properties, overrides some pages, etc.) XE xar that is to be used by all the created workspaces. The problem is that, being part of the platform, this creates a cyclic dependency in maven thus breaking the build. Also, the 3.2RC1 release is supposed to be today, so the matter is rather urgent. To fix this, there might be a couple of solutions on which I`d like your opinion/vote: 1) Rewrite the workspace-template module and, instead of using maven to produce a customized XE xar, use velocity within the workspace application to enhance a standard XE xar at runtime, when actually creating the workspace. (needs some time) 2) Move the workspace-template module into the XEM build and bundle workspace by default with XEM. (quick to do) 3) Move the workspace-template module into the XE build, even though workspaces is not bundled by default with XE. (quick to do, but not necessarily right) 4) Unlink the workspace module from the platform build, so that it is skipped from the build and that it does not break it, but leave the hooks. (quick to do, leaves way for further work) 5) Just revert everything related to workspaces from the platform and possibly keep the existing work in a branch. (quick to do, but also removes the hooks) Here's my +1 for 2). Thanks, Eduard

12 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2011