Hello team,
I am meeting a query at startup of my xwiki (3.1) which takes more than three minutes.
delete from xwikiproperties where xwp_name like 'editbox_%' and xwp_classtype='com.xpn.xwiki.objects.LongProperty'
I don't find where that query is made anymore, Google is becoming worse and worse to search for XWiki things, but I vaguely remember something about it.
Do you all agree it is useless a delete?
Should I create an SQL index just for that?
thanks in advance
paul
Hi devs,
XWiki is planning to participate in this year's Google Summer of Code [1].
The organization registration period has already started and the deadline
is the 9th of March [2] (a bit more than one week).
1. We need to provide by then a list of proposals and assign mentors for
the students that are going to implement them.
I would like to ask everybody that wants to participate as a mentor from
the XWiki organization to review the proposals [3] list (that is currently
empty) and add as many interesting proposals as possible.
The proposals can be either new, or they can be revived from previous year
proposals. Just navigate to the previous years, find the proposal you like
and know about, go to its proposal page (click it) and press the "Clone to
this year" link. Now you can assign yourself as lead for that project,
update it's description if needed and wait for the student applications to
start pouring :)
2. We also need to submit the actual application [4] of the XWiki
organization to participate to the GSoC 2012 project so I would also like
to ask you to review it so that we have a better chance of being selected
into the program.
Thanks for your help,
Eduard
----------
[1] http://www.google-melange.com/gsoc/homepage/google/gsoc2012
[2] http://www.google-melange.com/gsoc/events/google/gsoc2012
[3]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects28…
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicat…
Hi devs,
Right now renaming a key is a pain if we don't want to loose the
existing translations associated to it. Basically it require to rename
the key in all languages and reimport all of them on l10n.xwiki.org.
We already have a section in the translation file to indicate which
translations are deprecated. The idea is to indicate what is the new
name of a deprecated translation key directly in the translation file
so that l10n.xwiki.org can automatically copy the translation to the
new key when it find a new deprecated key while importing default
translation file.
For that we need to decide a syntax to indicate what is the new name of the key.
I propose to do something similar to java and indicate it in a comment
like the following:
new.key.name=Default translation
#@deprecated new.key.name
old.key.name=Default translation
Here are some other alternatives to "deprecated":
* replacedBy
* new
others ?
Here is my +1 for "deprecated", more intuitive for Java developers and
it's clear it's a deprecated translation key.
Thanks,
--
Thomas Mortagne
Hi devs,
>From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi Thomas,
I'm having problems with the cache tests for infinispan. They take a very long time to execute locally and some fail:
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.xwiki.cache.infinispan.InfinispanCacheTest
Tests run: 10, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 103.143 sec <<< FAILURE!
Running org.xwiki.cache.infinispan.InfinispanConfigTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec
Running org.xwiki.cache.infinispan.InfinispanLocalCacheTest
Tests run: 10, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 102.152 sec <<< FAILURE!
Results :
Failed tests: testCreateAndDestroyCacheLRUMaxEntries(org.xwiki.cache.infinispan.InfinispanCacheTest): No value has been evicted from the cache
testCreateAndDestroyCacheLRUTimeToLive(org.xwiki.cache.infinispan.InfinispanCacheTest)
testCreateAndDestroyCacheLRUAll(org.xwiki.cache.infinispan.InfinispanCacheTest)
testCreateAndDestroyCacheLRUMaxEntries(org.xwiki.cache.infinispan.InfinispanLocalCacheTest): No value has been evicted from the cache
testCreateAndDestroyCacheLRUTimeToLive(org.xwiki.cache.infinispan.InfinispanLocalCacheTest)
testCreateAndDestroyCacheLRUAll(org.xwiki.cache.infinispan.InfinispanLocalCacheTest)
Tests run: 21, Failures: 6, Errors: 0, Skipped: 0
Any idea?
Thanks
-Vincent
Is there a way in XWiki's velocity to process an XML document? I want
to parse a SPARQL Query Results XML document [1] returned by a custom
script service.
Thanks!
[1] http://www.w3.org/TR/rdf-sparql-XMLres/
--
Mark Wallace
Principal Engineer, Semantic Applications
Modus Operandi, Inc., FL, USA
Hi Devs,
I would like to commit the following change on the internal API of the
hibernate store:
Deprecate
public boolean beginTransaction(boolean withTransaction, XWikiContext
context)
public boolean beginTransaction(SessionFactory sfactory, boolean
withTransaction, XWikiContext context)
in favor of
public boolean beginTransaction(SessionFactory sfactory, XWikiContext
context)
Deprecate
public void endTransaction(XWikiContext context, boolean commit,
boolean withTransaction)
public <T> T execute(XWikiContext context, boolean bTransaction,
boolean doCommit, HibernateCallback<T> cb)
in favor of
public <T> T execute(XWikiContext context, boolean doCommit,
HibernateCallback<T> cb)
and add new method
public <T> T failSafeExecute(XWikiContext context, boolean doCommit,
HibernateCallback<T> cb)
Deprecate
public <T> T executeRead(XWikiContext context, boolean bTransaction,
HibernateCallback<T> cb) throws XWikiException
in favor of
public <T> T executeRead(XWikiContext context, HibernateCallback<T> cb)
throws XWikiException
and add new method
public <T> T executeFailSafeRead(XWikiContext context,
HibernateCallback<T> cb)
Deprecate
public <T> T executeWrite(XWikiContext context, boolean bTransaction,
HibernateCallback<T> cb)
in favor of
public <T> T executeWrite(XWikiContext context, HibernateCallback<T>
cb) throws XWikiException
and add new method
public <T> T failSafeExecuteWrite(XWikiContext context,
HibernateCallback<T> cb)
My motivation:
- reduce confusion, since the current signature let you think that
sub-transaction are possible, and these are not, since the withTransaction
argument is unused.
- provide an easy way to run potentially failing transaction, that will
not do logging and neither throw. It is the responsability of the caller to
manager the situation.
The later could be use to easily check the state of the database during a
migration for example. Is a table exists ? is column exists ? could be done
by simple fail safe selection, if these fail, you are almost sure the table
or column is missing.
Anything against these changes ?
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
For xwiki-platform in https://github.com/xwiki/xwiki-platform , no matter which branch I choose, I always got the 4.0-snapshot ,How can I get a stable one ? Thanks for helping me. Could express my thanks in this way ?I'm sorry my Englist is poor .
Hi,I want to download the code of stable-3.5 version from https://github.com/xwiki ,but they're all snapshop-3.5 version which is shown in pom.xml ,why? Is it ok?
Right now on an empty wiki you have all the rights except "delete"
(and register).
So this means that you have "admin" right but you don't have "delete" rights...
This does not make much sense and I anyway I don't see why delete has
this special rule.
Any idea ?
Here is my +1 to remove the special handling of "delete" default right.
--
Thomas Mortagne
Hi devs,
I noticed that we don't have a standard rule for naming component hints.
So far we have:
A) nestedscriptmacrovalidator -> concatenated word list
B) extension.cluster -> dot separated word list
C) CommentEventGeneratorListener -> CamelCase word list
D) legacyEventDispatcher -> camelCase with lowercase first letter
E) componentManagerBridge -> same, but getName returns the space
separated version
F) document-content-annotation-updater -> dash separated word list, but
getName returns the CamelCase version
G) register-macros-on-import -> same, but an active voice is used instead
There are probably other versions as well, I just looked at
EventListener implementations.
So, which one should we use?
Personally I'd vote for F)
Second vote: For EventListeners, should the getName() always return the
same thing as the component hint, or return a more user friendly
description? If we're returning a different thing, then we could return
a space separated description.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
If I build my project on Xwiki, I just want to use some of the modules ,
page editing ,for example . How can I do that ,Do I need to build all the
source in Xwiki platform .
Hi devs,
It's time to prepare the roadmap for 4.0. I know we haven't defined the Theme for 4.x yet but we've started the user survey at http://www.xwiki.org/xwiki/bin/view/Main/SurveyXWikiFeatures2012 and we need to wait a bit to get some relevant feedback. I'll get a summary of what we have so far in a few days.
After having brainstormed with some of you here's what I have found so far below for 4.0 (Caleb, Denis, I haven't put your items below since I wasn't sure what you'd like to work on so please free to add them yourself in reply).
If you have your name mentioned below please confirm that you can do it for 4.0 in the defined time frame.
If you wish to do some other stuff please add them in reply.
After a few days I'll move this on xwiki.org as our official roadmap for 4.0.
Dates
=====
- 4.0M1: 12 March 2012
- 4.0M2: 26 March 2012
- 4.0RC1: 9 April 2012
- 4.0 Final: 16 April 2012
Items
=====
* App Within Minutes improvements - Assignee: Marius
- Marius can you list specific items in some priority order?
* Extension Manager improvements - Assignee: Thomas and Marius (UI)
- Thomas can you list specific items in some priority order too?
- One that I know of is improved XAR merging and a nice UI for it
- One nice goal to have for 4.0 and 4.1 (I think we need 2 releases) is: "Be able to upgrade a XWiki Farm in 5 minutes". This is without the WAR upgrade, only the XAR part. This means upgrading the default XE and any installed extensions, for XE and for a farm.
* Hidding Technical Content (especially on Home Page) - Assignee: Jean-Vincent and Vincent
- My idea is to implement http://markmail.org/thread/jupn22fdk4nnqj6p but we need to brainstorm with JV and we'll send a proposal on the list soon about it
* Getting Started Guide on XE/XEM Home page - Assignee: Jean-Vincent
- JV to make a proposal to the list
* LDAP Admin UI - Assignee: Jerome Velociter
* Various Important JIRAs to fix:
- Backend Stuff
-- Page creation date should be the date of the installation - XWIKI-7058
-- Reduce the likelihood of having duplicate (hibernate) id for different documents and objects - XWIKI-6990
-- When using filesystem attachments with attachment versioning disabled, deleted attachments are duplicated on the hard disk. - XWIKI-6951
-- Deleted attachments duplication in recycle bin while File Storage is on - XWIKI-6917
-- Renaming a page should also rename the title of it - XWIKI-6743
-- Be able to rename a space from the UI - XWIKI-6722
-- Problems displaying the correct attachment version when using a proxy - XWIKI-6569
-- Performance of blog category panel is still not enough - XWIKI-6363
-- Change stylesheet and javascript extension filename when a modification is done on those - XWIKI-6073
-- Auto-create Space.WebHome when creating a page in an underfined space - XWIKI-5399
-- OpenOffice Issues on Windows (bug) Jira to be created - XWIKI-7510
-- OpenOffice automatic connection to external daemon - XWIKI-7509
- Frontend stuff
-- Add more/all configuration parameters in the wiki administration - XWIKI-7066
-- Log-in automatically on registration - XWIKI-6892
-- Limit dragable width of textareas in FF4 and Chrome - XWIKI-6304
-- WebSearch should only display spaces with view right - XWIKI-6227
-- Auto-suggest doesn't work for global users - XWIKI-6207
-- Activity Stream doesn't show Image Profile change - XWIKI-5930
-- Cannot filter using "/" on a Date column in the livetable - XWIKI-5889
-- Better placement of the documentation link - XE-1031
-- New XWiki Syntax Guide - XE-880
-- Occasionally the livetable fails to load on index pages XE-844
-- Add option to 'show more entries' on displaying the Activity Stream XE-748
-- Timezone Setting by User - Jira to be created
* Investigations:
- Home Page Changes Proposals - Assignee: Caty and JV
- Search Investigation (Improvements to current or SOLR) - Assignee: Need volunteer
Thanks
-Vincent
Hi devs,
Based on the work done by Anca and Sorin doring the XWiki 2011 Seminar
Hackaton, I`ve made the following pull request [1] to integrate their work
with minor changes.
A summary of the changes contained by the pull request are described in the
jira issue [2].
The problem at the current stage, as Jerome also hinted, is that we need to
do a migration script to make the existing annotations (in an upgrade
scenario) use the XWikiComments class instead so that they can be picked up
by commentsinline.vm. However, this might lose the possibility to provide
custom annotations.
An alternative would be to make commentsinline.vm use the annotation
service and handle and retrieve both Annotation and XWikiComment objects.
This way, the current annotations should need no migration script since
they are using a class configured in the AnnotationConfig page that the
annotation service knows how to handle.
WDYT?
Thanks,
Eduard
----------
[1] https://github.com/xwiki/xwiki-platform/pull/34
[2] http://jira.xwiki.org/browse/XWIKI-7540
Hi devs,
I've worked on a LDAP administration UI (see
http://jira.xwiki.org/browse/XWIKI-2551). It's an improved version of
the admin UI that the LDAP admin tools
(http://extensions.xwiki.org/xwiki/bin/view/Extension/LDAP+Tools)
provides. Compared to the extension, it brings more descriptive labels
for each field, and provides rich property editors for mappings (user
field mapping and LDAP group mapping), fixing two weak points of the
LDAP tools app (the form was too complex to fill in and field mapping
format in a textarea not intuitive).
You can see it in a branch on github :
https://github.com/xwiki/xwiki-platform/compare/master...ldap-ui
I would like to add the module in XWiki platform for 4.0.
My +1 for it.
Now another question is, should we bundle it by default ?
Personally I think not. I think we should point to it in xwiki.cfg
LDAP section and on xwiki.org documentation. The rationale is that
only a small subset of users are interested by this UI, and for the
other it is confusing. And now we have a good extension manager,
adding this UI is just a couple of clicks away for those interested.
Thanks
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
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.
This is a stabilization release that brings many improvements to the
Extension Manager, a new macro for displaying documents in a live
table and quite a few bug fixes. XWiki Enterprise 3.5 is the last
major release of the 3.x development cycle (there will still be bugfix
releases on the 3.5.x branch, if needed). The next major release is
going to be 4.0.
See the full release notes at
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…
for more details.
Thanks
-The XWiki dev team
I have read most of the document offered by thie Xwiki site,but I still
don't know how to build my project .If I want to write my own projects
completely ,what do I need at least?
I am sorry that Englist is not my native language ,I hope I have deliver
what I want to say to you .
A suggest: Download the source is really difficult for a new comer,can we
sugges a convient way ?
BEST WISHES FOR YOU !
Hi devs,
I'd like to propose forking wikimodel (http://code.google.com/p/wikimodel/) and move its source code into our code base in XWiki Rendering as a separate module for now.
Motivation
========
* Wikimodel has been inactive for years (since 2009). Actually that's not quite true, there's been one developer working on it regularly, it's Thomas Mortagne…
* We heavily depend on wikimodel in the XWiki Rendering module (for our syntax parsers) which is a key module for XWiki
* It's more difficult for us to contribute to the wikimodel project since it means:
** committing in a different project with different rules
** there's nobody doing releases on the wikimodel projet and we need the releases to be synced with our releases since otherwise we cannot release on a SNAPSHOT dependency
** there's no community there so it's not fun and doesn't help for quality control/reviews/etc
** since we push XWiki Commons and XWiki Rendering to Maven Central we also need the wikimodel releases to be pushed to Central which is not happening now
* The wikimodel project has a different scope than our need. Mikhail (owner and admin of Wikiodel - not active since 2009 - some commits here and there) wanted it to remain only for wiki syntaxes. We added support for HTML parsing in it but Mikhail never liked it and wanted us to move it to XWiki.
* We have some impedance mistmatch between the wikimodel model and the xwiki rendering model which causes us to do some circumvolution in the code which leads to issues still beeing open in our JIRA (they've been opened for a long time now)
* We believe wikimodel would benefit from a larger and active community within the XWiki ecosystem. Wikimodel has been stagnating for years and we'd like it to live on and evolve.
Action Plan
=========
Thus Thomas and me are proposing to do the following:
* Move the sources in a new rendering module as is and use it as a library (same as now except we rename the module name and release it under the XWiki umbrella).
* Modify all header to put our LGPL headers everywhere
* We keep the attribution as is recommended by the ASL (see http://www.apache.org/foundation/license-faq.html#Distribute-changes) by adding a comment to all sources explaining where the source come from and in which license it was and who authored the initial code and how XWiki committers have participated to the wikimodel project. We also put that information in the NOTICE file.
* We modify the source code slowly over time to integrate it cleanly without our code and remove the hacks we had to do, and we bring improvements
* We post a mail on the wikimodel mailing list explaining all this and inviting the current wikimodel committers to become committers on the xwiki rendering module (provided they agree to follow our dev rules). We also explain how contributors can contribute (link to jira, link to github for pull requests, etc)
Related question (not part of the vote)
=============================
* We could decide to move XWiki Commons and XWiki Rendering under the ASL since they're libraries and as libraries the ASL is the license that makes it the easier possible to use from all other licenses. Right now ASL code cannot use our Rendering module because we're LGPL.
Here's my +1 to this plan.
I'm also currently +1 to brainstorm about moving XWiki Commons and XWiki Rendering to the ASL.
Thanks
-Vincent
Hi i'm new using a xwiki.
I'm trying to make a plugin that allows me to create users on the wiki.
but not where to start, I've read the documentation, but I can not connect
anything.
would appreciate your help.
--
View this message in context: http://xwiki.475771.n2.nabble.com/plugin-xwiki-tp7285335p7285335.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.
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 Milestone 1.
This release brings many improvements to the Extension Manager, a new
macro for displaying documents in a live table and quite a few bug
fixes. This is the only milestone of the 3.5 release, which is the
last release of the 3.x cycle. The next planned release is 3.5 final.
See the full release notes at
http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris…
for more details.
Thanks
-The XWiki dev team
Hi devs,
I know this subject will seems to you already voted and discussed in
http://xwiki.markmail.org/thread/fsd25bvft74xwgcx
But following the remarks and the discussion under that thread, I had
largely improved the proposed changes.
This is an important matter, so I prefer to resume here to be sure we all
really agree on this.
To resume the current situation, we have:
- document id
- used in document table, rcs, attachment...
- simple 32bits string hashcode of a locally serialized
document reference, including the language for translated documents
- stored in a 64bits field.
- object id
- used in object and property tables, but also in statistics tables
- simple 32bits string hashcode of the concatenation of the document
reference, the class reference and the object number
- stored in a 32bits field (except in Oracle, where the mapping is
32bits, but the storage is larger)
The vote is about:
- document id
- use the lower 64bits of an MD5 hashcode
- the base key for the hashcode is serialized using a
LocalUidEntityReferenceSerializer of the document reference
- the result is appended with the current locale for translated
document, until locale are integrated in references
- format for original document: 5space8document
- format for translation: 5:space8:document2:fr
- object id
- use the lower 64bits of an MD5 hashcode
- the base key for the hashcode is serialized using a
LocalUidEntityReferenceSerializer of the BaseObjectReference
- current format would be: 5:space8:document12:xspace.class[0]
- if my proposal in the object reference thread is adopted:
5:space8:document18:6:xspace5:class[0]
Since changing document id could really not helps since document reference
are used in object ids and therefore unambiguous document could
receive ambiguous objects, I do not advice to split the change. Moreover,
this is really sensible change in the database, so not multiplying them is
better. I think the upcoming 4 is a really good time to introduce this
change, so I propose to introduce this in version 40000 of the database
(4.0M1 release).
But I would like to use it internally earlier. So you would be pleased to
settle on this thread and the previous one before.
It implies the following migration for existing instances:
- customer custom mapping have to be adapted before the migration,
including dynamic one which could be not so easy, but this is already
rarely used and very rarely require any change in fact.
- change XWikiDocument to provide the key required for IDs, by the way,
also use that key (non local version) for the document cache
- refactor the BaseElement hierarchy to provide long IDs (no more
integer) based on references (generic way to have ids for any element)
- change the hibernate mapping for all object ids
- provide dynamic schema updates using liquibase to fix all object id
types, including those in custom mapping and collection
- migrate in HQL document id for persisted
class: XWikiDocument, XWikiRCSNodeInfo, XWikiLink, XWikiAttachment,
DeletedAttachment
- migrate in HQL object id for persisted class: BaseObject, *Property,
internal custom mapped class, dynamic custom mapped class
- migrate in HQL object id for custom statistics class derived form
XWikiStats
- migrate in SQL ids for all relational collections in the above migrated
tables
To provide this migration as safely as possible:
- Liquibase provide a safe way to change the schema
- All id conversion are gathered from the database in a first single
read-only transaction, and new id are computed.
- Potentially already migrated ids are detected, allowing the process to
fails and be restarted.
- Proceed to ids replacement using a safe algorithm that may support
non-circular conflict between old and new ids (very unlikely anyway, since
we move from 32 to 64bits)
- Use a single transaction for each id conversion, replacing it in all
related tables
- Use Database independent queries (HQL) as much as possible, only bulk
update on collection which are not supported by hibernate are in a
minimalistic SQL update statement.
Some helps for testing the migration on different
environments is requested ! (I do my tests on MySQL deeply)
I will commit my branch on platform soon.
Here is my +1.
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO