xwiki-devs

xwiki-devs@xwiki.org

9400 discussions

[xwiki-devs] [Announcement] XWiki Enterprise and XWiki Enterprise Manager 4.0 released

by Thomas Mortagne

The XWiki development team is pleased to announce the release of XWiki Enterprise and XWiki Enterprise Manager 4.0. Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download This is the first release of the 4.x cycle. See http://enterprise.xwiki.org/xwiki/bin/view/Main/Roadmap for more informations about the 4.x cycle. The highlights of this release are: * reduced document database id collision. It has been well tested but you might want to make sure you have a working backup of your database. * new LDAP administration UI * Annotations merged with Comments * Extension Manager improvements * App Within Minutes improvements * User profile customization * User directory improvements and user customized view * ColorThemes gradients customizable from ColorTheme Wizard * New IRC Bot Application On development side: * Extension Manager (without xar support and wiki UI) is now part of XWiki Commons project and can be easily used outside of XWiki * Component roles are now based on java.lang.reflect.Type instead of java.lang.Class which mean you can now have different roles with the same class and different generic types (e.g. ) * New Velocity tool to serialize Java objects to JSON format * Class reference always local * New Rights Implementation (Experimental). You can enable and test it in xwiki.cfg. * New technical content hiding system * A new ApplicationReadyEvent event has been introduce for component that need to access the database at init. For more information see the Release notes at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise40 and http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXEM40 Thanks -The XWiki dev team

12 years, 8 months

[xwiki-devs] [VOTE] Stop bundling the Event Syntax in XE?

by Vincent Massol

Hi, I've now put the Event Renderer in its own syntax module, same as what we have for other syntaxes. Thus we need to decide if we still want to bundle it in XE or not (it was bundled but only because it was in rendering-api before). IMO there's no reason to bundle it at all since: * it's not used anywhere * I don't see any use case for it (we use it only for tests) * We want to reduce the # of extensions we bundle by default * It can be added by the user in his XE instance should he need it (I doubt it) So here's my +1 to not bundle it and to add this potential backward compat breakage in the RN for 4.1M1 Thanks -Vincent

12 years, 8 months

[xwiki-devs] WYSIWYG toolbar features

by Geo Du

Hi, all, I have a problem to add more tools onto the toolbar with xwiki 3.5 I am using, I like to add Text Alignment, Fonts, TextSize, colors, but I checked this link:http://platform.xwiki.org/xwiki/bin/view/Features/WysiwygEditor, it is for 2.0, where is the toolbar configuration information about the 3.5 version? I could not find from the admin guide. Also from the WYSIWYG editor configuration class, https://sipa.mol.fi/xwiki/bin/view/XWiki/WysiwygEditorConfigClass, it does not define all the tool bar items. Would you please point me to the right direction to look at? Thanks very much!! Dave

12 years, 8 months

[xwiki-devs] [Announcement] XWiki Enterprise 3.5.1 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.5.1. This is the first bugfix release for the 3.5 series, and, since 3.5 is the final major release in the 3.x cycle, a bugfix release for the whole 3.x cycle. The main focus has been on quality assurance, improving the compatibility with various database systems, polishing the new sheet mechanism, the new extension manager, the skin, the WYSIWYG, and other parts of the XWiki platform. See the full release notes at http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise351 for more details. -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 8 months

[xwiki-devs] [Reminder] Deprecation day tomorrow (26th of April)

by Vincent Massol

It's tomorrow, the 26th of April, don't forget! Goal: * Move as many deprecations to legacy modules Who: * All committers and all contributor who wish to help out Metric: * Our score will be the # of APIs moved. Each dev need to report the # of APIs he's moved. Let's make it a success and learn from it. I'll publish a blog post with the result afterwards. Thanks -Vincent

12 years, 8 months

[xwiki-devs] XWiki databases testing helper script and repository for unreleased but maintained codes

by Denis Gervalle

Hi devs, Following the numerous database related issues that have/are delayed/ing the 3.5.1 release and the 4.0 release, and seing how it could be long and annoying to put multi-database tests in place, and the hard work Sorin has done in testing these issues again and again, I have taken a couple of hour to write a decent bash script. Here is an excerpt of the usage message of my script: This script can do the following steps easily to help you testing xwiki distribution: - Download a distribution package, either release or snapshot (using mysql/jetty distribution). - Deploy that package, and configure it for a requested database. - Create the needed database. - Import a database dump, previously exported with this same tool. - Launch the configured XWiki with Jetty. - Backup the database after XWiki shutdown. All operations could be done in a multiuser environment, using common databases, without conflict. You may start using it as easy as "xwiktest -v 3.5 -d oracle -w" to have a XWiki release 3.5 downloaded and run with oracle and non-conflicting ports and database. Full options are listed at the end of this thread for the interested. I really hope this script could help in testing more often any changes that may have consequences between versions, or may cause incompatibilities with some databases. It would be nice if a well connected VM (the one from Sorin has all DBs well configured but is badly connected and downloading is really slow :( ) could be available to all committers, avoiding each one to have to setup each database locally. If you find it useful, I will maintain this script as much as possible, and improve it further. I have already some idea like: - automatically import a given XAR - check logs, terminate and report issue automatically (to integrate with Jenkins?) - allow starting multiple version one after each others, testing migration in one run ... This is already more than a simple script (~500 lines), and well documented. However, I do not found a good place to put such script in GitHub. IMO, this script is like release scripts, it will be maintained by the dev team, and it could became essentiel to the project, and I have conform as much as a bash script could to our coding practices. Therefore I do not think that putting it in xwiki-contrib is right. Release scripts should not even be there, and need a place in a xwiki repositories IMO. These are scripts that are never released nor compile or what ever. We have already something similar in xwiki repositories: xwiki-debug-eclipse I do not think it is nice to multiply repositories in xwiki, but there is a need for unreleased but maintained codes like these. I proposed that we create a new repository in XWiki to contains such codes, and to put/move in it: - xwiki-debug-eclipse - xwiki-release-tools (for release scripts) - xwiki-testing-tools (for the above script) We may call this repository: - xwiki-tools - xwiki-utils - xwiki-dev-tools ... WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO As promised for the curious, the options of my testing script: Usage: xwikitest [OPTIONS] Options: -b backup.sql Backup database to the given file (or folder for oracle) after shutdown. -B backup.sql Backup current database to the given file, same as -b -z -k -n -d database Choose a database (mysql-myisam,mysql-innodb,psql,oracle,hsqldb). Current is mysql-innodb. -e distribution Choose a distribution (enterprise or manager). Current is manager. -i dump.sql Import the given sql dump in the database before startup. -I dump.sql Import the given sql dump in the database without running, same as -i -z -n -h Display this usage message. At the end, it shows your current arguments and alone the defaults. -k Do not clean the database before startup. -n Do not start XWiki. -p port Port for Jetty listening. Current is 7581. -r snapshot Use given snapshot (ie: 20120410.161114-97). Default to use release. -s dbsuffix Database suffix for test isolation. Current is DenisG. -t port Port for Jetty termination. Current is 7501. -v version Choose a XWiki version. Current is 4.1. -w Download from maven.xwiki.org. Default is to search current folder. -z Do not redeploy and reconfigure (use with care).

12 years, 8 months

[xwiki-devs] jQuery is undefined error for IE7

by Geo Du

Hi, all, I am using jQuery for javascript, since it is conflicting with prototype, I use the jQuery help extension: http://extensions.xwiki.org/xwiki/bin/view/Extension/jQuery+Helpers, so far everything works fine on Firefox, the problem is the IE7, I got jQuery is undefined error from the UI library: $xwiki.jsx.use("jQuery.jQueryUI"), I can see the javascript code in firebug with last par of the code: .bind("blur",h)})})})(jQuery); I noticed that there is a ";" in the end, but in IE7, I checked the code from Microsoft Script Editor when I debug, it shows no ";", not sure if that is the problem. In IE7, I clicked the jQuery helper extension demo pages: bin/view/jQuery/Demo1 page and bin/view/jQuery/Demo2 page, they both gave me "jQuery is undefined" error. so this error happens to the extension as well. Could anybody help me with is issue? Thanks very much. Dave

12 years, 8 months

[xwiki-devs] [VOTE] Legacy Module Rules

by Vincent Massol

Hi devs, In preparation of our Deprecation Day and continuing our vote on the Deprecation strategy I'd like to propose several rules we need to clarify since we need them and I'd like to finish documenting our full deprecation strategy. Rule 1: Where are Legacy modules located? =================================== * Proposal: - Each Git repository needing legacy modules provides a *-legacy module for holding legacy modules. For example: -- For Commons, xwiki-commons-core/xwiki-commons-legacy/ -- For Platform, xwiki-platform-core/xwiki-platform-legacy/ -- For Rendering, xwiki-rendering-legacy/ * Explanation: - It's better to locate them in a specific module (*-legacy) than inside their own module (for ex in xwiki-commons-core/xwiki-commons-component/xwiki-commons-component-legacy/) because legacy modules are something we don't want to see as much as possible since we're must not use them in our code, thus it's logical to park them all together somewhere. * Notes: - This is our current rule but it's never been explicitly defined Rule 2: What do Legacy modules contain? ================================= * Proposal: - Each Legacy module should replace the non-legacy module it corresponds to. This means that the user must have only 1 JAR for a given module: either its legacy version or it's non-legacy version but should never have both. * Explanation: - We need consistency. Right now we have oldcore which acts like this but others don't and it's complex to explain to users that for some they have to swap them and for others they have to keep both side by side - In the very close future, we'll use a lot of Aspects in modules others than legacy-oldcore, and thus we'll need to apply this strategy anyway. * Notes: - Currently, only oldcore acts like this. - The consequence is that we'll have one legacy module per non legacy modules. Right now we sometimes have one legacy module for several non legacy modules which we'll need to fix Here's my +1 to both. Thanks -Vincent

12 years, 8 months

[xwiki-devs] [VOTE] Changing our deprecation strategy (TAKE2)

by Vincent Massol

Hi devs, I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming: * Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules Here's my +1 Thanks -Vincent

12 years, 8 months

[xwiki-devs] Simple Mobile Skin

by Ludovic Dubost

Hi, I've been working a while ago on a Mobile Skin which principle is the following: 1/ Light UI adapted to mobile devices, both phones and tablet (with a particular attention to tablets), giving most of the screen real estate to the page content 2/ Support all Javascript normally supported in the XWiki skin in order for any code inside pages that would use this Javascript to still work 3/ Automatic detection of mobile devices to make them switch to the mobile skin 4/ Ability to switch from mobile to normal skin 5/ compatibility with color themes I believe this approach is the right one, as XWiki instances do have significant Javascript and in order to make sure these pages work, we need to be able to accept this javascript. Of course some other improvements could be done, for example to have a mobile friendly dashboard or livetable. Now this work has had a few iterations with particularly some relooking work from Caty. The work is published here: http://extensions.xwiki.org/xwiki/bin/view/Extension/SimpleMobileSkin And the code is available here in both XAR and File-System version (for XEM): https://github.com/ldubost/xwiki-mobileskin The skin can be tested on the incubator (although there is not the automated switch) http://incubator.myxwiki.org/xwiki/bin/view/Improvements/34Proposal?skin=XW… I've also worked on integrating this in the platform. The commit is available in a fork on github: https://github.com/ldubost/xwiki-platform/commit/064baeb017b35e08a526029381… I'd like some comments and discussion so that we can bring this into the platform. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs