The XWiki development team is pleased to announce the release of XWiki
Enterprise 2.0 Release Candidate 2.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download
This is the last release candidate before the XWiki enterprise 2.0 final version
69 Jira issues has been closed for this release.
Changes from 2.0 Release Candidate 1:
* New Colibri skin improvements
* General UI improvements
* WYSIWYG improvements
* Rendering 2.0 improvements
* New regexp velocity tool
* Update translations: de, fr, gl, ru, sk, lv, pl, sv, zh, ro, ua,
ko, hi, cs
As usual we need the community to heavily test this release before the
final release to catch all the remaining issues.
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC2
Thanks
-The XWiki dev team
Hi devs,
Here is a vote for the release of the last (hopefully) release
candidate of XWiki Enterprise 2.0.
The main goal of this release is to introduce the new Colibri skin and
new title handling policy by default. It's also supposed to be a real
release candidate (meaning that it's supposed to be the final release
if nothing critical is found).
See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20RC2
for more details.
Here is my +1
--
Thomas Mortagne
Hi All,
I'm working on designing LiveTable 2.0 macro, an xwiki/2.0 macro that is
supposed to work similar to current LiveTable (say 1.0) Macro. By looking at
LiveTable 1.0 macro code I encountered few problems that confuses me a lot.
* First, LiveTable macro is different from other macros (those I have seen /
written so far) in which the generated content is "live"... Normally macros
replaces the macro block with some other generated content but here
LiveTable macro makes use of AJAX to fetch content dynamically. So the
question, is LiveTable a macro or is it something else? Stuffing
JavaScript/AJAX code inside a rendering 2.0 feels unfamiliar to me.
* Second, existing LiveTable macro can be viewed in several ways:
1. Way of presenting a list of documents containing an object of a specific
class.
2. Way of presenting a list of documents matching a criterion.
3. Generic way of presenting information mactching a criterion.
I'm having a hard time figuring out what should be the exact purpose of
LiveTable 2.0 macro, should it be same as LiveTable 1.0 macro?
* Third, LiveTable macro uses several resources.
1. XWiki.LiveTableResults
2. XWiki.LiveTableResultsMacros
3. LiveTable JavaScript widget & CSS
If we decide that LiveTable 2.0 macro should serve the same purpose as
LiveTable 1.0 macro, should these resources be reused? (within the 2.0
rendering macro)
Please help me to clarify these issues, I'm a bit lost here.
Many thanks.
- Asiri
Hi,
We now used $msg.get() eveywhere in the default XAR. IMO this is bad
for the following reasons:
* Our search no longer returns hits since it searches on the page
content in the database (web search). BTW this is why some REST tests
were failing since the content no longer existed for it (it does a
hibernate search).
* Users get to see $msg.get() everywhere in document titles when they
edit XE pages, which is ugly and not understandable for simple users
(for ex check Main.WebHome).
* It's not a good way to translate apps since we bundle app
translations keys in the core jar! Apps should be self-standing
What should we do instead?
Proposal:
* Use the xwiki page translation feature...
* Provide a XAR with all languages (and possibly a XAR per language).
If the user configures his wiki for one language he'll see only that
language (make sure all translations are imported even when in mono
language)
* Refactor existing pages to separate content from code. Move code to
separate pages included from content pages. Never put content in code
pages, have it passed to velocity macros for example.
On the technical side we need to verify it can work but this is way
better and would address the shortcomings listed above.
Thanks
-Vincent
Hi,
I'd like to set the compat flag on for now since we haven't converted
all page titles yet and this is going to take some time.
We should move it back to off when it's all converted.
+1
Thanks
-Vincent
Too bad Groovy isn't in here: "Alternative Languages on a JVM"
http://www.azulsystems.com/events/javaone_2009/session/2009_J1_JVMLang.pdf
...
> Deeper Dive
> Clojure - “almost close”
● Good: no obvious subroutine calls in inner loop
● Bad: Massive “ephemeral” object allocation -
requires good GC
● But needs Escape Analysis to go really fast
● Ugly: fix-num overflow checks everywhere
● Turn off fix-nums: same speed as Java
● Weird “holes” -
● Not-optimized reflection calls here & there
● Can get reports on generated reflection calls
10
Deeper Dive
> Jython - “almost close”
● Also has fix-num issue; massive allocation
● Some extra locks thrown in
> JavaScript/Rhino - “almost close”
● All things are Doubles – not 'double'
● Same fix-num allocation issues as Clojure, Jython
● Otherwise looks pretty good (no fix-num checks)
> JRuby – Missed The Metal
● Assuming CachingCallSite::call inlines
● Using -XX:+PrintInlining to determine
● But flag is lying: claims method inlined, but it's not
11
Common Issue – Fix-Nums
> Huge allocation rate of “fix-nums”
● Allocation is not free
● Setting final fields cost a memory fence
● GC does NOT cost here
● i.e., object pooling would be a big loser
> Could do much better with JIT
● Need “ultra-stupid” Escape Analysis
● Need some (easy) JIT tweaking
● e.g. Getting around Integer.valueOf(i) caching
12
JRuby – Missed The Metal
> Each minor action dispatches via “call”
> Assuming CachingCallSite::call inlines
● (and allows further inlining)
> Using -XX:+PrintInlining to determine
> But flag is lying: claims inlined, but it's not
● BimorphicInlining is 'guessing' wrong target
> Confirmed w/GDB on X86 Java6
> Confirmed w/Azul profiler
● My 1st impression: can't be inlined ever
Niels
http://nielsmayer.com
Hi,
Here are skin problems I can see that need to be fixed before the RC1
release:
1) ColorTheme space is not excluded for simple users
2) On admin page the large header is not correctly positioned
3) Colibri is not set to be the skin by default
4) Colibri is not using the voted default colors
5) The colorTheme property is not set in XWikiPreferences
6) There's no theme editor/chooser available from the admin
presentation page
7) Ugly (too large) create button on the blog home page
8) Blog title is no longer using the Blog object title value
9) When going to a blog post page there are 2 dup titles that really
don't look nice
10) Use profile page has dup titles. XWiki.User does not start
directly with the title, but wraps it inside a vcard microformat.
11) Main.WebSearch is not a plain title, but also contains an icon
link to the RSS results. The document should be updated.
12) Main.Tags does not have a heading, but a div styled to look like a
heading. Also, it is not a simple title, it also incorporates tools
for the selected tag.
Anything else that is a blocker for the RC1 and 2.0 final release?
Can we spread the work amongst ourselves? Please volunteer to take
some items.
Note1: This means that we're late yet again since today is supposed to
be the release day for RC1... This means we need to finish all the
items above today at latest.
Note2: I haven't looked at existing colibri skin issues already in
jira. Please someone have a look and add to the list above if they are
blocker for RC1.
Let's crack this all together today!
Thanks
-Vincent
Hi,
Following our discussion on the new title behavior we need to define
the title compat flag value.
I'm proposing:
#-# Defines whether title handling should be using the compatyiblity
mode or not. When the compatibility
#-# mode is active, if the document's content first header (level 1 or
level 2) matches the document's title
#-# the first header is stripped.
xwiki.title.compatibility=0
+ we need a way to access this property from contentview.vm so I'm
proposing to also add a method to api.XWiki:
isTitleInCompatibilityMode()
WDYT?
Thanks
-Vincent
Hi,
For some reasons, I build XWiki Enterprise with netbeans and maven.
I checkout http://svn.xwiki.org/svnroot/xwiki/enterprise/trunk, I choose
project "XWiki Products - Enterprise - Web (war)", I run, and I see in my
navigator :
Etat HTTP 500 -
javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error number 3
in 0: Could not initialize main XWiki context
Wrapped Exception: Error number 3001 in 3: Cannot load class
com.xpn.xwiki.store.migration.hibernate.XWikiHibernateMigrationManager from
param xwiki.store.migration.manager.class
Wrapped Exception: Error number 0 in 3: Exception while hibernate execute
Wrapped Exception: Hibernate Dialect must be explicitly set
I read in googled world there is a hibernate.cfg.xml. In my checkouted
directory, there is a checkout/trunk/web/src/main/webapp/WEB-
INF/hibernate.cfg.xml, but this file is empty ?
Is it this file ?
I read some parts on
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationHSQL but I
can't see a complete model hibernate.cfg.xml
Thanks for your help.