Hi Geeks
I just uploaded the first draft of the Blog Application in Grooyv:
http://jira.xwiki.org/jira/browse/XABLOG-81
You need to install the Blog Plugin (also attached there) and then
import the XAR file. It uses its own space called "GBlog" and so you
don't need to worry that Blog is gone because of it.
The current state is that most of the staff works (sort of) including
the panels but:
1. The application is not up to date with the latest code
2. Some stuff might look ugly or does not work properly. If so please
let me know.
3. I need to redesign the Groovy structure to take better care of the
code. I postponed that so far because I wanted to make sure I had a
good picture of all the problems with the rewrite.
Let me know what you think.
Cheers - Andy
On Sep 27, 2009, at 5:18 AM, sdumitriu (SVN) wrote:
> Author: sdumitriu
> Date: 2009-09-27 05:18:20 +0200 (Sun, 27 Sep 2009)
> New Revision: 24079
>
> Modified:
> platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> XWikiDocument.java
> Log:
> XWIKI-4416: Add getPrefixedFullName in XWikiDocument
> Done.
>
> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/
> doc/XWikiDocument.java
> ===================================================================
> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> XWikiDocument.java 2009-09-27 02:37:41 UTC (rev 24078)
> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
> XWikiDocument.java 2009-09-27 03:18:20 UTC (rev 24079)
> @@ -651,12 +651,20 @@
> public String getFullName()
> {
> StringBuffer buf = new StringBuffer();
> - buf.append(getSpace());
> - buf.append(".");
> + buf.append(getSpace()).append(".");
> buf.append(getName());
> return buf.toString();
> }
>
> + public String getPrefixedFullName()
> + {
> + StringBuffer buf = new StringBuffer();
> + buf.append(getDatabase()).append(":");
> + buf.append(getSpace()).append(".");
> + buf.append(getName());
> + return buf.toString();
> + }
Shouldn't users of this method instead use DocumentName?
Couldn't we instead introduce a getDocumentName() in XWikiDocument. Of
course if the calling code needs a string (which it shouldn't except
in very rare cases but right now it's possible it needs one because
not all our api are using DocumentName) then it can use the
DocumentNameSerializer.
Thanks
-Vincent
fyi
-Vincent
Begin forwarded message:
> From: Mark Miller <markrmiller(a)apache.org>
> Date: September 25, 2009 6:15:57 PM CEDT
> To: announce(a)apache.org
> Subject: The Release of Lucene 2.9
> Reply-To: markrmiller(a)apache.org
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hello Lucene users,
>
> On behalf of the Lucene dev community (a growing community far larger
> than just the committers) I would like to announce the release of
> Lucene 2.9.
>
> While we generally try and maintain full backwards compatibility
> between major versions, Lucene 2.9 has a variety of breaks that are
> spelled out in the 'Changes in backwards compatibility policy' section
> of CHANGES.txt.
>
> We recommend that you recompile your application with Lucene 2.9
> rather than attempting to “drop” it in. This will alert you to any
> issues you may have to fix if you are affected by one of the backward
> compatibility breaks. As always, its a really good idea to thoroughly
> read CHANGES.txt before upgrading.
>
> Lucene 2.9 comes with a bevy of new features, including:
>
> * Per segment searching and caching (can lead to much faster reopen
> among other things)
>
> * Near real-time search capabilities added to IndexWriter
>
> * New Query types
>
> * Smarter, more scalable multi-term queries (wildcard, range, etc)
>
> * A freshly optimized Collector/Scorer API
>
> * Improved Unicode support and the addition of Collation contrib
>
> * A new Attribute based TokenStream API
>
> * A new QueryParser framework in contrib with a core QueryParser
> replacement impl included.
>
> * Scoring is now optional when sorting by Field, or using a custom
> Collector, gaining sizable performance when scores are not
> required.
>
> * New analyzers (PersianAnalyzer, ArabicAnalyzer,
> SmartChineseAnalyzer)
>
> * New fast-vector-highlighter for large documents
>
> * Lucene now includes high-performance handling of numeric fields.
> Such fields are indexed with a trie structure, enabling simple to
> use and much faster numeric range searching without having to
> externally pre-process numeric values into textual values.
>
> ---
>
> And many, many more features, bug fixes, optimizations, and various
> improvements. You can find the full list of changes here:
>
> http://lucene.apache.org/java/2_9_0/changes/Changes.html
>
>
> Many changes have also occurred in Lucene's Contrib area:
>
> http://lucene.apache.org/java/2_9_0/changes/Contrib-Changes.html
>
>
> Binary and source distributions are available at
> http://www.apache.org/dyn/closer.cgi/lucene/java/
>
> Lucene artifacts are also available in the Maven2 repository at
> http://repo1.maven.org/maven2/org/apache/lucene/
>
> The Next Release:
>
> The next release will be Lucene 3.0. This should come along shortly,
> and will
> remove all of the deprecated code in Lucene 2.9. Lucene 3.0 will also
> be the
> first release to move from Java 1.4 to Java 1.5 as a requirement.
>
>
> Thanks,
>
> Mark Miller
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBCgAGBQJKvOy9AAoJEBMFmEzrAZn4rmYP/AsmtlRAOZzCUyGo83pkYyPx
> kR2XdaZPUN8Le5RdaW2BuYtm+i3OLhsLFrWeJwCm/DrFM7tTlwLtFGFnYyga3BM6
> L+TCVmgMOke1Mo36E/Sjn6+aPcXLZK/HMb5EHuoYpZZAk7Vx+jsWmTpHPvP5HR4t
> ZXNa6CT9wjaK1iV7nvaJnifC5QjPeDncM2qOQWF5wLY26eS/G7a4dXJOsl6IHP7z
> uJ2j7fxMSucvSGOzWNjW9SouymVuYqL5m4KyEeiqwUlGvHPfLn1AySmCYClEhSL1
> 5kI0Fmr6z6duPY/LKvTNVTe2S1tQS8DKErtOP2vbclglvuw//dqp/cbjvjP8oTZg
> 5B610ehDBNwmKN5DAq8v1PAj0vGj1ygk9hotXFcjGlnEEoTCPegh1P3lg0t0LKlk
> vBt5GJC61+8dJMs0BXRznSESV8dl7IjjBzfnGiEqQS1sSGBGxAzgUHaOrVnHW/vh
> BfaNwzqFguYvOXMzV8DkwQPpXMOxDMDEHKjAKj3SSYsIAIPLbRP0XwkU2Y6csfoP
> rrom1+fZEkNFd/qbQw2i7xhvX1LmShlT6GYezkR9St+fSoWzg2Js44dSpDAYYh33
> 3Ngz6koNyZVCfcwz1oOMI5yz+oD98OICxyG0j/m6w8RtEAhsUE07tX/LEvHp0HPZ
> uF1TIGPZcQbC4g3yf8Kz
> =WImG
> -----END PGP SIGNATURE-----
>
Hi,
I would like to start the release of XWiki Enterprise 2.0 final.
It's a very important release so make sure there is no blocker
remaining on your side before voting.
You can look at
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise20
for more details.
Here is my +1
Thanks,
--
Thomas Mortagne
On Sep 24, 2009, at 8:54 AM, Marius Dumitru Florea wrote:
> Hi Vincent,
>
> vmassol (SVN) wrote:
>> Author: vmassol
>> Date: 2009-09-23 23:45:22 +0200 (Wed, 23 Sep 2009)
>> New Revision: 23882
>>
>> Modified:
>> enterprise/branches/xwiki-enterprise-2.0/distribution-test/
>> wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java
>> Log:
>> Try to fix flickering test
>>
>> Modified: enterprise/branches/xwiki-enterprise-2.0/distribution-
>> test/wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/
>> LinkTest.java
>> ===================================================================
>> --- enterprise/branches/xwiki-enterprise-2.0/distribution-test/
>> wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java
>> 2009-09-23 21:22:39 UTC (rev 23881)
>> +++ enterprise/branches/xwiki-enterprise-2.0/distribution-test/
>> wysiwyg-tests/src/test/it/com/xpn/xwiki/it/selenium/LinkTest.java
>> 2009-09-23 21:45:22 UTC (rev 23882)
>> @@ -167,7 +167,7 @@
>> /**
>> * Test the basic feature for adding a link to a new page in a
>> new space.
>> *
>> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3511
>> + * @see <a href="http://jira.xwiki.org/jira/browse/
>> XWIKI-3511">XWIKI-3511</a>
>> */
>> public void testCreateLinkToNewPageInNewSpace()
>> {
>> @@ -931,7 +931,7 @@
>> /**
>> * Test that editing a link with custom parameters set from
>> wiki syntax preserves the parameters of the link.
>> *
>> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3568
>> + * @see <a href="http://jira.xwiki.org/jira/browse/
>> XWIKI-3568">XWIKI-3568</a>
>> */
>> public void testEditLinkPreservesCustomParameters()
>> {
>> @@ -988,8 +988,8 @@
>> /**
>> * Test that quotes in link tooltips are correctly escaped.
>> *
>> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3569
>> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3575
>> + * @see <a href="http://jira.xwiki.org/jira/browse/
>> XWIKI-3569">XWIKI-3569</a>
>> + * @see <a href="http://jira.xwiki.org/jira/browse/
>> XWIKI-3569">XWIKI-3575</a>
>> */
>> public void testQuoteInLinkTooltip()
>> {
>> @@ -1267,7 +1267,7 @@
>> /**
>> * Test that a relative link is correctly edited.
>> *
>> - * @see http://jira.xwiki.org/jira/browse/XWIKI-3676
>> + * @see <a href="http://jira.xwiki.org/jira/browse/
>> XWIKI-3676">XWIKI-3676</a>
>> */
>> public void testEditRelativeLink()
>> {
>> @@ -1851,7 +1851,7 @@
>>
>> protected void waitForStepToLoad(String name)
>> {
>> - waitForCondition("selenium.isElementPresent('//
>> *[contains(@class, \"" + name + "\")]');");
>
>> + assertAndWaitForElement("//*[contains(@class, '" + name +
>> "')]");
>
> I find "assertAndWait.." a bit confusing since I'm thinking that it
> asserts something and then waits for the element to be present. From
> the
> code it looks like the method just waits for the element to be
> present.
> Why not simply "waitForElement"?
Agreed.
Thanks
-Vincent
jvelociter (SVN) wrote:
> Author: jvelociter
> Date: 2009-09-22 16:05:56 +0200 (Tue, 22 Sep 2009)
> New Revision: 23823
>
> Added:
> platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/XWikiServletResponseStub.java
> Modified:
> platform/xwiki-plugins/trunk/scheduler/src/main/java/com/xpn/xwiki/plugin/scheduler/SchedulerPlugin.java
> Log:
> XASCH-39 Stub the servlet response in the scheduler's thread context
A response stub and a request stub are needed for all background
threads. Thus, it would be better to move them in xwiki-core.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi Devs,
Right now the Colibri skin introduces 2 new components (among others):
- a search box in the header
- a "create" menu entry in the top action bar that allows user to create
new pages / spaces
Those 2 new features duplicate the Create Page & the Search panel and thus
make those panels irrelevant in the default distrib.
I'd like to send a vote on removing those 2 panels from the right column in
the default XAR & updating the release notes accordingly (so that toucan &
albatross users know how to get them back easily).
Here's my +1 to remove both panels from the right column in the default XAR.
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
My loader is able to load every page in my copy of XE and they all pass the .equals( test against
the same page loaded by the default loader so I feel that I'm ready to publish some tests.
These are time results (in milliseconds) for loading a page containing 1000 comments.
see: http://jira.xwiki.org/jira/browse/XWIKI-2874
My test script runs the tests 30 times interchanging old loader and new.
These tests were all the first call to a newly started server, you can see it speed up
as the code is jit compiled.
Conclusion:
850% improvment can be expected for loading a page with 1000 comments.
StringListProperty and LargeStringProperty being mapped to the same column costs about
100ms for the workaround, disabling this workaround brings it to an even
1000% speed increase.
Disabling custom mapping saves a whopping 8ms. This surprised me.
My loader is only marginally faster at loading all of the pages in XE, it is best
at scaling with lots of objects. This didn't surprise me.
The actual test results are below.
Caleb James DeLisle
test1:
no special optimizations.
Old loader ===================== New Loader
11835ms. ===================== 2875ms.
7776ms. ===================== 771ms.
6827ms. ===================== 684ms.
6652ms. ===================== 405ms.
4406ms. ===================== 348ms.
3790ms. ===================== 363ms.
3482ms. ===================== 288ms.
3431ms. ===================== 965ms.
3173ms. ===================== 295ms.
3029ms. ===================== 271ms.
3714ms. ===================== 278ms.
3017ms. ===================== 285ms.
3828ms. ===================== 271ms.
2907ms. ===================== 285ms.
2845ms. ===================== 258ms.
2884ms. ===================== 275ms.
2829ms. ===================== 276ms.
2871ms. ===================== 256ms.
3638ms. ===================== 285ms.
2797ms. ===================== 295ms.
old loader's average: 4284.6ms.
new loader's average: 501.4ms.
test2:
this is with the LargeString/StringList workaround disabled.
Old loader ===================== New Loader
11494ms. ===================== 1541ms.
8916ms. ===================== 902ms.
7209ms. ===================== 639ms.
5584ms. ===================== 365ms.
4649ms. ===================== 324ms.
3700ms. ===================== 275ms.
3454ms. ===================== 282ms.
3391ms. ===================== 258ms.
3875ms. ===================== 260ms.
3087ms. ===================== 260ms.
3714ms. ===================== 342ms.
3012ms. ===================== 279ms.
3045ms. ===================== 1109ms.
3012ms. ===================== 242ms.
2873ms. ===================== 244ms.
2863ms. ===================== 247ms.
2880ms. ===================== 257ms.
2842ms. ===================== 276ms.
3667ms. ===================== 255ms.
2881ms. ===================== 259ms.
old loader's average: 4305.3ms.
new loader's average: 430.8ms.
test3:
LargeString/StringList workaround & custom mapping disabled.
Old loader ===================== New Loader
11813ms. ===================== 1465ms.
7984ms. ===================== 853ms.
6819ms. ===================== 602ms.
6182ms. ===================== 373ms.
4609ms. ===================== 320ms.
3749ms. ===================== 280ms.
3484ms. ===================== 309ms.
3348ms. ===================== 269ms.
3797ms. ===================== 263ms.
3119ms. ===================== 257ms.
3733ms. ===================== 327ms.
3044ms. ===================== 274ms.
2985ms. ===================== 1086ms.
2864ms. ===================== 239ms.
2888ms. ===================== 265ms.
2854ms. ===================== 262ms.
2836ms. ===================== 264ms.
2835ms. ===================== 269ms.
3653ms. ===================== 241ms.
2843ms. ===================== 247ms.
old loader's average: 4269.8ms.
new loader's average: 423.2ms.
I am investigation the possibility to write Panels in Groovy. Unfortunately I am not able to figure out:
- if I XWiki would render Groovy script code by itself and if how ?
- If not can I render a Groovy script form another Groovy script ?
BTW I was stuck for a while when trying to create my own BlogPostTemplate because XWiki would not allow me to run it as Groovy script even if I gave myself programming rights. But when I wrote the BlogPostSheet as Groovy class and loaded it inside the Velocity script of the BlogPostTemplate it worked perfectly. Now I am wondering why I could not execute the Groovy script if I can circumvent this restriction so easily.
Cheers - Andy
Hi everyone,
Example:
----- %> cut here --------
...
something
#end ## some comment
{{warning..../}}
----- %> cut here --------
Quizz: Will the macro be inline or standalone?
Answer: inline
Reason is that velocity will start by removing the comment, which will
leave a whitespace after the #end
Thus you'll get:
something + NL + (space) + NL + warning macro
Thus since there are no 2 NLs before the macro it's going to be inline!
Thanks
-Vincent
Since we're not maintaining it and can't guarantee it's quality and
since nobody is working on it today.
We can put it back when it's updated and working fine.
Note: even if we put it back it should be done differently and not as
part of platform IMO. Probably an end product.
Here's my +1
Thanks
-Vincent
Hi,
Following our previous discussion (see http://markmail.org/thread/5lsaq274tvczr5wd)
, I'd like to move this forward. Here's what I propose now:
1) We create a new "XWiki Core" (key: XCORE) jira project which is
where we put the new components and where we invite everyone to create
new core issues.
* In this new jira project we use the rule of one jira component per
module, whatever the size of the module.
** For example for the rendering module (which is our largest module
right now) this means one jira component only. In order to make it
easy for users we should name it with something like "Rendering (wiki
syntaxes, macros, ...)"
** Users will simply need to explain what it's about in the issue
title. For example instead of having a "Rendering - Macro - RSS"
component the issue will be named "Add blahblah feature to the RSS
macro"
** Having lots of modules might look better but I think 1) having too
many components make it hard for end users to find the right one and
2) I don't see real needs for them. Do you see any?
2) We keep the existing "XWiki Core" (key: XWIKI) jira project but:
** we change its permissions so that no new issues can be created in it
** we change its name to "XWiki Core - Old"
** we change its description to tell people to use the other one with
a link to it
** we add a welcome message in the default dashboard to explain the
change and point people to the new jira project.
** we slowly move whatever issues we can from it to the new project.
For example we can easily move all Rendering 2.0 issues or all GWT
WYSIWYG issues. For the rest we can move other time whenever we
encounter an issue that should go in the new jira project
3) We change our existing jira filters so that they include both XCORE
and XWIKI jira projects.
WDYT?
If we agree, I can start doing this.
Thanks
-Vincent
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