The XWiki development team is proud to announce the availability of XWiki
7.1.1.
This is a stabilization release that fixes important bugs discovered in the
7.1 version.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki711
The following people have contributed code to this release:
- Vincent Massol
- Guillaume Delhumeau
Thanks for your support
-The XWiki dev team
Hi,
This mail is about dropping support for Colibri Skin [1].
Colibri Skin has been developed in version 2.0 (Sep 2009) and used as a
default Skin until version 6.2 (Sep 2014), when it was replaced by Flamingo
Skin [2].
Colibri is still supported for 6.x branch (currently we are developing
version 6.4.5).
Since the Flamingo Skin had stabilized, I propose we drop support for
Colibri Skin in 7.x, in order to focus on Flamingo.
This means the improvements and bugfixes will not be mandatory to be ported
on Colibri anymore.
We can still have Colibri bundled for one more cycle and after we can
retired it.
WDYT?
Here is my +1
Thanks,
Caty
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Colibri+Skin
[2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Flamingo+Skin
[3] http://design.xwiki.org/xwiki/bin/view/Proposal/SupportSkin
The XWiki development team is proud to announce the availability of XWiki
7.1
This release adds important changes and improvements for Extension Manager,
Solr Search, Watchlist, a new experimental Flavors mechanism and a Debug
mode for performance analysis.
Extension Manager provides a summary for the extension diff view in order
to ease the navigation of the local code changes. A new Extension History
section has also been added, offering support for selective export, import
and replay of extension-related history records.
Solr Search UI is improved by making it responsive on small screens. The
users can now sort, paginate and filter the search results without a page
reload.
The Flavors and Watchlist Realtime option are currently still experimental,
but you are encouraged to test them and provide feedback.
The WatchList performance has been improved, especially for the Realtime
notification option. The Realtime Watchlist messages are displayed in a
more user-friendly way, sending mails for a variety of events, threaded by
your email client by the document they occurred in.
The Flavor mechanism is allowing the selection of Flavors in the wiki
creation step. In the future, XWiki will offer different Flavors and these
are steps towards this direction.
Under-the-hood there are various mail and job module improvements. The
developers can now trigger old Prototype event listeners from jQuery and a
new API is available to escape wiki syntax.
You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download
Make sure to review the release notes:
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki71
The following people have contributed code to this release:
Thomas Mortagne
Vincent Massol
Guillaume Delhumeau
Eduard Moraru
Marius Dumitru Florea
Denis Gervalle
Sergiu Dumitriu
Manuel Smeria
Gabriela Smeria
Ecaterina Moraru (Valica)
Anca Luca
Jean SIMARD
Clemens Robbenhaar
Thanks for your support
-The XWiki dev team
Hi devs,
With the intoduction of http://jira.xwiki.org/browse/XWIKI-12171 (Add a script right to manage script macro execution permissions) in 7.2, we should also think about renaming what we call "Programming Right" (PR for short) since "Script" and "Programming" are close. At least to change that in the UI (and possibly even at API level by introducing new methods ands deprecating old ones).
First step would be to find a new name. I can think of:
* Privilege Right (nice thing is that PR is still valid ;)) http://dictionary.reference.com/browse/privilege  "a right, immunity, or benefit enjoyed only by a person beyond the advantages of most:". This would mean that people with the Privilege Right would be able to use Privileged APIs.
* System Right
* God Right
My preference goes to "Privilege" or "Privileged".
WDYT about
1) Changing the name
2) The new name to use if you agree with 1)
?
Thanks
-Vincent
Hi Devs,
At http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HDatabaseModel I have started drafting some naive impl for Nested Spaces. I believe Edy has provided some other links with probably more elaborate algorithms that we should study (such as http://www.slideshare.net/billkarwin/models-for-hierarchical-data).
In any case I’ve also started a Problem section at http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HProblems where I’ve listed one item FTM. I’m pasting it here:
“
* For ex if you do HQL (or you use an extension that does) like {{code}}where doc.space = 'somespace'{{/code}} and add a parent or child Space for ##somespace## then the query will not return anything anymore since you can have something like ##parent.somespace.child## in the DB in the ##space## column (since we store the full space reference in there for NS).
** Solution 1: Rewrite the queries to use something like {{code}}where doc.space = 'somespace' or doc.space like '%.somespace'{{/code}}.
** Solution 2: Don't modify the ##space## column and add a ##spaceReference## one. This is not perfect in case there are several spaces named ##somespace##
** Solution 3: ??
“
I’d be curious to know what you think about it and if you have ideas.
Feel free to list other problems you can see there and your ideas for solving them.
Thanks
-Vincent
Hi devs,
I’d like to propose that we agree about:
* using JDOM2 when needing to parse/output XML files
* moving away existing code gradually from DOM4J to JDOM2
Rationale:
* It would be nice to pick one fwk and have more consistency
* DOM4J seems not maintained anymore:Â https://sourceforge.net/projects/dom4j/files/
* JDOM2 seems maintained:Â http://jdom.org/news/
WDYT?
Thanks
-Vincent
Hi Devs,
Here are some proposals below that I have discussed with committers from XWiki SAS already.Â
For all other committers (thinking about Denis, Sergiu, Clemens, or others), feel free to add other stuff you’d like to do in 7.2.
Content
=======
Large topics:
- Nested Spaces (yeah!) - See http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces - Thomas/Marius/Guillaume/Edy/Caty/Gabriela/Vincent. See also the mail I sent a few days ago on this: http://markmail.org/message/sl3n3gvcxbsp2l6k
- Add a new right to allow users to write scripts in wiki pages - Eduard
Proposed Dates
==============
- 7.2M1: 6 JulyÂ
- 7.2M2: 3 August
- 7.2M3: 24 August
- 7.2RC1: 7 September
- 7.2Final:Â 14 September
Note: There are lots of people going on holidays during the summer which is why I’m proposing a longer time frame than usual for 7.2. In addition Nested Spaces is a complex topic to implement so we’ll need this time :)
Let me know if there are any concerns.Â
Thanks
-Vincent
Hi devs,
The time has finally come! We’ve been discussing for a long time about implementing Nested Spaces in XWiki but we’ve never had the time to do it. It was raised for example in http://jira.xwiki.org/browse/XWIKI-354 in 2006! :)
This has been discussed internally at XWiki SAS and XWiki SAS has agreed to put all its devs on it for 7.2. To be fully transparent, a client of XWiki SAS is helping sponsor this feature if we can have a first version in 7.2 and a full implementation by the end of the year.
We’ve (We = the XWiki core committers who work for XWiki SAS) started an early design of what needs to be done at http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces
With this email I’d like to ensure that all XWiki Dev Team committers agree to include the Nested Spaces feature in 7.2. The idea will be to mostly implement it in this release and then to fine-tune/polish/fix issues in 7.3 and 7.4 so that by the end of the year it’s fully implemented.
Of course there’ll be plenty of discussions/decisions to make and they’ll all be discussed on this list, as usual.
Note that I plan to send the usual roadmap proposal for 7.2 at the end of this week but I wanted to make sure we’d agree about developing this feature first! (I hope we do agree :)).
WDYT?
Thanks
-Vincent
Hi devs,
Could be interesting to use this okHttp when we need to manipulate URL/URI. Obviously we shouldn't drop URL/URI in APIs since that’s the standard…
It allows to more easily parse query strings too.
Anyway this is just some idea and more a FYI.
See https://corner.squareup.com/2015/05/okhttp-2-4.html
Thanks
-Vincenr