The XWiki development team is pleased to announce the release of XWiki
Enterprise 1.3 final.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This release spanned 2 full months starting on the 10th of January
2008 and ending on the 7th of March 2008. During that period we
implemented over 200 issues, fixing close to 100 bugs and adding new
features such as:
* Ability to export pages as HTML in a zip file
* Ability to export the current page in a XAR
* Better Oracle support
* New Toucan skin
* Complete rewrite of the LDAP authentication support including
the support for LDAP groups
* Diff emails sent by the Watchlist feature + ability to
customize the email sent
* Improved translation (German, French, Spanish) + new
transaltions (Slovak)
Main changes from 1.3RC1:
* Core changes:
o Bugs
+ XWIKI-1850 - No security against recursive includes
+ XWIKI-2047 - DB2 Hibernate Mapping for 1.2
+ XWIKI-2163 - XWiki.parseGroovyFromPage() doesn't
work when passing the a page containing JARs to be put in the Groovy
classloader
+ XWIKI-2164 - Cannot log out
+ XWIKI-2171 - When user is not in the bind_DN/
bind_pass search for DN from user uid fail
o Improvements
+ XWIKI-2157 - Add Slovak translation
+ XWIKI-2170 - Allow inactive users to see specific
pages
* Albatross Skin:
o Bugs
+ XSALBATROSS-18 - Parse error when serving skin.js
through SkinAction
* Toucan Skin:
o Bugs
+ XSTOUCAN-11 - RSS macro isn't styled correctly in
Toucan
+ XSTOUCAN-12 - In inline edit mode all the input
fields are stretched to the full content width
+ XSTOUCAN-13 - Numbered lists do not appear as
numbered
+ XSTOUCAN-17 - Bulletted lists do not show bullets
in the WYSIWYG editor
o Improvements
+ XSTOUCAN-14 - In admin mode allow clicking anywhere
on a tab to select it
+ XSTOUCAN-15 - Increase size of info box displayed
by the #xwikimessageboxstart macro
+ XSTOUCAN-16 - Remove borders for tables using the
memberstable class id
* Watchlist plugin
o Bugs
+ XPWATCHLIST-20 - Exception on Scheduler.WebHome
about "isDocumentWatched"
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise13
Thanks
-The XWiki dev team
Hi,
I'd like to commit a new service : criteriaService [1]. This service,
both available from java and velocity, allow to get various criteria
(most of them extracted from the statistics plugin) :
- Duration, a length of time
- Period, a length of time defined by a min date and a max date
- Range (formerly named Interval), an integer range (also allow to
sublist a list according to the range)
- RevisionCriteria, criteria to match document revisions (author, min
date, max date, minor edits)
- Scope, define an xwiki scope (page, space, wiki)
Since 4 of those objects are from the statistics I've refactored the
plugin and the application.
Modifications in the public APIs : duration,period,range and scope
factories won't be available from the statsService anymore since they
have moved to criteriaService.
Please shout if you're using any of those methods from velocity :
- $xwiki.getStatsService().getDurationFactory()
- $xwiki.getStatsService().getPeriodFactory()
- $xwiki.getStatsService().getIntervalFactory()
- $xwiki.getStatsService().getScopeFactory()
Additions :
- Document.getRevisions(RevisionCriteria), allowing to get document
revisions matching the criteria
- ListTool added to the rendering velocity context ($listtool)
First use case, in the watchlist plugin the diffs sent by email will
contain all the revisions since the last email notification (was : a
diff between the last 2 revisions) [2].
[1] http://jira.xwiki.org/jira/browse/XWIKI-2159
[2] http://jira.xwiki.org/jira/browse/XPWATCHLIST-15
JV.
Hi Devs,
Where can i find more details about the Component Based Architecture of
XWiki ?
I need as much information as possible.
Sorry if the source of information is obvious, i couldn't do much search coz
my machine is almost stuck running a neural network training algorithm (for
my final year project)
Thanks a lot.
- Asiri
Hi,
I was in a dire need to extended on of the xwiki plugin classes
MailSenderPlugin because xwiki implementation does not handle the password
authentication to smtp servers that require one.
I was unable to do so because the said class is declared final.
My only option is to modify the xwiki code itself to make the desired
change, but I certainly want to avoid this as I want to use only xwiki
binaries to take advantage of future functionality implementation and bug
fixes in by xwiki team.
So is there any specific reason why these classes were defined as final?
Is there anyway I can add such functionalities to xwki plugins without
modifying the xwiki source.
Thanks
Sachin
-----
http://www.assembla.com/wiki/show/sachin_mittal about me:
--
View this message in context: http://www.nabble.com/Why-are-certain-Plugin-classes-final-tp15891099p15891…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
Here's the new concept: as much people as possible in the XWiki
community must spend 1 hour on Wednesday, 5th of March 2008 (today,
sorry for the late announcement) and write documentation for 1 hour on
xwiki.org. This is an effort to improve the quality and content of our
documentation.
Rules:
* 1 hour
* You choose at what time you want to work on the documentation.
However most of us will be starting at 14:00 GMT+1.
* On xwiki.org
* You choose to document what you want. Ideas of missing documentation:
- In JIRA: http://tinyurl.com/3xtn8t
- Improve existing documentation
- XWiki Watch documentation on http://watch.xwiki.org
- XEM Documentation on http://manager.xwiki.org
* Make sure you create a jira issue for the work you're doing and
assign to yourself. The issue should be created in the XWiki Core
project, with a "documentation" component.
* If you can't do it on the 5th, then you can still do it on another
day, as close as possible to the 5th of March ;)
* The idea is to repeat this event every month or every 2 months.
Thanks everyone, let's see what we can do with the power of the
community! :)
-Vincent
Hi,
I've just seen that we have a XWiki.getFlash() method which just
renders a flash.vm template which simply output an <object
classid=...> to display a flash animation.
This has nothing to do in the core proper IMO.
I propose to move this in the macro.vm as a #flash macro.
WDYT?
Here's my +1
Thanks
-Vincent