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/