Hi devs,
I'd like to move all XE modules to org.xwiki instead of com.xpn for XE 2.6.
Rationale:
* XE is an open source project and com is commercial
* Our rule was to keep com.xpn for old stuff but this doesn't make sense for XE modules since they're not old stuff
+1 from me
Thanks
-Vincent
I installed XEM and getting the following error.
Any idea why am i getting this? I guess there
are no mysql connectivity problem since the
database tables were created when I tried to
instantiate the XEM.
type Exception report
message
description The server encountered an internal error () that prevented
it from fulfilling this request.
exception
javax.servlet.ServletException: com.xpn.xwiki.XWikiException: Error
number 3 in 0: Could not initialize main XWiki context
Wrapped Exception: Error number 3201 in 3: Exception while saving
document xwiki:XWiki.XWikiPreferences
Wrapped Exception: Failed to commit or rollback transaction. Root cause []
org.apache.struts.action.RequestProcessor.processException(RequestProcessor.java:535)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:433)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:129)
com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:152)
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:304)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
root cause
com.xpn.xwiki.XWikiException: Error number 3 in 0: Could not
initialize main XWiki context
Wrapped Exception: Error number 3201 in 3: Exception while saving
document xwiki:XWiki.XWikiPreferences
Wrapped Exception: Failed to commit or rollback transaction. Root cause []
com.xpn.xwiki.XWiki.getMainXWiki(XWiki.java:402)
com.xpn.xwiki.XWiki.getXWiki(XWiki.java:471)
com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:136)
com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:116)
org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431)
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236)
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
com.xpn.xwiki.web.ActionFilter.doFilter(ActionFilter.java:129)
com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:152)
com.xpn.xwiki.plugin.webdav.XWikiDavFilter.doFilter(XWikiDavFilter.java:68)
com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:304)
com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112)
In order to make direct sql queries as similar to hql as possible (and as easy as possible), I
propose that for any new database columns or tables, we begin using column names which match the
name of the java object properties, and table names which match the class name.
I would like to put a note at the top of xwiki.hbm.xml which says:
<!--
All new table names should be all lower case versions of the name of the class which they represent
for example:
XWikiDocument should map to a table called xwikidocument
All new column names should be all lower case versions of the property which they represent for example:
fullName should map to a column called fullname
-->
WDYT?
Caleb
Hin
I'd like to rename {{uservatar}} macro to {{avatar}} (ie deprecate the {{uservatar}} alias) + rename the current "username" parameter to "name":
{{avatar name="XWiki.VincentMassol" /}}
Rationale:
* Macros should be as easy to use as possible and avatar is easier and shorter than useravatar (for several reasons shorter, no need to remember if there's an underscore, a dash, etc)
* We'll want to use that macro not only for user avatars but also for other potential use cases (group avatars for example). Note that the macro can autodiscover if the avatar reference is a user or a group but in case it isn't possible for other types it's always possible to add a type parameter later on.
Here's my +1
Thanks
-Vincent
Hi,
We put unit tests in the same package as the code they're testing. But for functional tests we need to define a best practice. Right now we have a mix of different strategies in enterprise tests for example and I'd like to homogeneize this.
I'm proposing to use: org.xwiki.test.*
For example for clustering tests in distribution-tests/cluster-tests, I'm proposing:
org.xwiki.test.cluster
org.xwiki.test.cluster.framework
Here's my +1
Thanks
-Vincent
Hi devs,
I noticed today that the time spent by Hudson to run all the WYSIWYG
selenium tests (274) has increased from 19 to 22 minutes although the
number of tests didn't change much from XE 2.4 and neither the tests'
code. I wanted to know if this was caused by an increased WYSIWYG editor
loading time so I did a quick profiling using Firefox 3.6.10 and Firebug
1.5.4.
The WYSIWYG editor loading time (alone, excluding other artifacts on the
host page) has three components:
(T1) time to interpret the WYSIWYG editor JavaScript code (~530KB)
(T2) time to load the edited document in the in-line frame
(T3) time to load the editor plugins and to initialize the UI (menu,
tool bar)
It seems that (T3) is:
* XE 2.4 -> 219.128ms, 26753 calls
* XE 2.5 -> 242.968ms, 28282 calls
Next I checked with Firebug's Net tab the page loading time. In order to
test the editor alone I created a simple velocity template (wysiwyg.vm)
that includes only the editor (plus the JavaScript and stylesheets
needed by the editor).
XE 2.4
------
4.35s -> WYSIWYG edit mode with SmartClient
2.47s -> WYSIWYG edit mode without SmartClient
3.4s -> xpage=wysiwyg with SmartClient
1.7s -> xpage=wysiwyg without SmartClient
XE 2.5
------
3.9s -> WYSIWYG edit mode with SmartClient
2s -> WYSIWYG edit mode without SmartClient
3.2s -> xpage=wysiwyg with SmartClient
1.3s -> xpage=wysiwyg without SmartClient
So the overall page loading time in edit mode has decreased. Also note
that SmartClient adds a lot of time and it is used only for the XWiki
Explorer tree..
This means the increased time spent on WYSIWYG selenium tests is caused
by something else.
Thanks,
Marius
Hi devs,
I'd like to propose that we don't maintain the Albatross skin anymore,
since it's time consuming to port all the UI improvements and fixes to it.
The skin will not be removed from the distribution yet, since it's still
the base skin on which Toucan and Colibri are built, although we should
try to fix this dependency in the near future.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
I'd like to create svn externals for enterprise in enterprise/trunks that would build both platform and enterprise. I would put a pom.xml in trunks for doing that.
The need is to have a single maven multi module project to run Clover on (otherwise it's more complex for setting up Clover).
WDYT?
Thanks
-Vincent
Hi Sergiu,
On Oct 17, 2010, at 3:33 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2010-10-17 03:33:22 +0200 (Sun, 17 Oct 2010)
> New Revision: 31913
>
> Modified:
> platform/xwiki-applications/trunk/administration/pom.xml
> Log:
> [misc] New version number
>
> Modified: platform/xwiki-applications/trunk/administration/pom.xml
> ===================================================================
> --- platform/xwiki-applications/trunk/administration/pom.xml 2010-10-17 01:10:40 UTC (rev 31912)
> +++ platform/xwiki-applications/trunk/administration/pom.xml 2010-10-17 01:33:22 UTC (rev 31913)
> @@ -31,7 +31,7 @@
> </parent>
> <artifactId>xwiki-application-administration</artifactId>
> <name>XWiki Platform - Applications - Administration</name>
> - <version>1.42-SNAPSHOT</version>
> + <version>2.0-SNAPSHOT</version>
Why are we doing this?
Did we agree about a strategy? I'm worried about aligning versions for all apps in case we decided something.
Thanks
-Vincent
> <packaging>xar</packaging>
> <description>Application for administrating wiki features like users, groups, rights etc.</description>
> <!-- We must configure SCM in each module. For more information see:
Hi,
I'd like to remove this package which doesn't seem to be used and is something used for testing and thus has nothing to do in src/main/java. In addition for tests we now use Greenmail.
Please let me know if you think this is used somewhere and I've missed it.
Thanks
-Vincent