Someone would need to try this version to see if it works and then we
could upgrade our version maybe.
-Vincent
Begin forwarded message:
> From: Dennis Lundberg <dennisl(a)apache.org>
> Date: July 14, 2009 3:54:40 PM CEDT
> To: announce(a)maven.apache.org, Maven Users List <users(a)maven.apache.org
> >
> Cc: Maven Developers List <dev(a)maven.apache.org>
> Subject: [ANN] Maven Checkstyle Plugin 2.3 Released
> Reply-To: "Maven Users List" <users(a)maven.apache.org>
>
> The Maven team is pleased to announce the release of the Maven
> Checkstyle Plugin, version 2.3
>
> The Checkstyle plugin generates report regarding the code style used
> by
> the developers.
>
> Important note: This version of the plugin uses Checkstyle 4.4.
> Version
> 2.3 will be the last version of Maven Checkstyle Plugin that will
> run on
> Java 1.4. The next version of Maven Checkstyle Plugin will be upgraded
> to Checkstyle 5 and will therefor require Java 5 to run.
>
> http://maven.apache.org/plugins/maven-checkstyle-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-checkstyle-plugin</artifactId>
> <version>2.3</version>
> </plugin>
>
>
> Release Notes - Maven 2.x Checkstyle Plugin - Version 2.3
>
> ** Improvement
> * [MCHECKSTYLE-101] - Skip should skip everything including the
> Velocity initialization
> * [MCHECKSTYLE-110] - option to output violations to the console
> when using chekstyle:check
> * [MCHECKSTYLE-114] - Add an ASF-compliant source release assembly
>
> ** New Feature
> * [MCHECKSTYLE-113] - Set the number of accepted violations for
> checkstyle:check
>
> ** Task
> * [MCHECKSTYLE-98] - Maven Checkstyle is too strict and not follow
> Maven's team conventions!
>
>
> Enjoy,
>
> -The Maven team
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe(a)maven.apache.org
> For additional commands, e-mail: users-help(a)maven.apache.org
>
Hi
I just uploaded an XAR export onto this JIRA report:
http://jira.xwiki.org/jira/secure/ManageAttachments.jspa?id=26378
It contains the changed documents supporting 2.0 syntax. For now the upgraded pages contain the suffix '2' including the WebHome which is called 'WebHome2'. To check out what I did please open this page 'Blog/WebHome2' to view the Blog.
To test it out download the attached file and import it (it will not overwrite any Blog documents).
I have 2 major issues so far:
1) The post is not displayed correctly (there is some mixup with Velocity and the startmacro and stopmacro comment.
2) The Categories / Archive Panel cannot be upgraded to 2.0 Syntax because the Panel is still in 1.0 syntax. I don't know how to resolve that except keeping the panel and the code pages available in 1.0 syntax.
I would appreciate if anyone could help me on number 1) because I don't know where start looking right now.
Cheers
Andreas Schaefer
CEO of Madplanet.com Inc.
EMail: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter: andy_mpc
AIM: schaefera(a)me.com
Hello Devs,
I want to store lucene index in database.is it possible to store lucene
index in database and make search on that index.
in short storing index in bd and access it from db.
BR,
Sayeem
H devs,
To implements wiki macros Adiri need componenet manager to support two
new things:
- unregister a component descriptor: when a wiki macro is removed and
does not exists anymore it you not be listed in components. This will
be also needed for application manager to be able to uninstall
application containing components.
- register component instance: wiki macro are based on WikiMacro
implementation of Macro component interface but with different datas
depending of the macro, to register this kind of macro as component we
need to be able to directly register the instance to use and not let
the component manager do the instantiation form the descriptor since
we cant add custom datas in component descriptor
Here is my +1 for both.
--
Thomas Mortagne
Hello,
I use virtual wikis and I have created a XAR by exporting from one wiki and
then importing the XAR into another wiki.
Then I choose a doc in the new wiki and I just want to copy it into another
document in the same wiki and it gives "Successfully copied" but when I
access the new doc, it says "your doc doesn't exist" and it is really
empty... No error anywhere...
After comparing with other documents I could copy without any problem, I
discovered that my doc has a parent such as "oldwiki:MySpace.MyParentDoc"
instead of "newwiki:MySpace.MyParentDoc". (I didn't set the parent using
virtual wikis explicitely, it was created by the wiki like that)
So apparently, the export keeps the parent name with wiki relationship. As
the export is just a raw serialization of the document structure, it is not
really surprising.
And the copy function fails to copy the document without any error.
regards
Pascal
Hello,
maybe I'm a bit stupid but I tried using the Groovy Console app
it works perfectly but it requires loading/saving scripts into
XWiki.ConsoleScriptClass.
But where is this class because I can't find it?
Moreover, when a script is stored in one object of this class, how to use
it? Is there a kind of extension such as jsx or ssx?
regards
Pascal
On Sat, Jul 11, 2009 at 10:09, Vincent Massol<vincent(a)massol.net> wrote:
> Summarizing (I've now understood):
> - We have input syntaxes (parser syntaxes) and output syntaxes
> (renderer syntaxes)
>
> Proposal
> =======
>
> a- we rename SyntaxFactory.getAvailableSyntaxes() in
> getAvailableInputSyntaxes() (or getAvailableParserSyntaxes())
+1 , since it's in rendering module we should always use same
vocabulary so +1 for getAvailableParserSyntaxes
> b- we add SyntaFactory.getAvailableOutputSyntaxes() (or
> getAvailableRendererSyntaxes())
+1 for getAvailableRendererSyntaxes
> c- (optional) we add a Renderer.getSyntax() interface method (for
> later use when renderers will be components)
let's wait for when we will make renderers componenents since it
depends on how we do that exactly
> d- we rename Document/XWikiDocument/XWiki methods for getting syntaxes
> to use Input/Ouput (or Parser/Renderer) in their names.
+1
>
> Note that b) means that we'll hardcode the list of available renderer
> syntaxes but that's ok for now (this is hat is currently done in
> PrintRendererFactory). This will be made dynamic when Renderer are
> made components.
The advantage of putting this in PrintRendererFactory is that you have
less chance to forget to update the list when you add a new renderer
but i doubt we will add one before making renderers real components
actually so i guess it ok.
>
> WDYT?
>
> Thanks
> -Vincent
>
> On Jul 10, 2009, at 6:49 PM, Thomas Mortagne wrote:
>
>> On Fri, Jul 10, 2009 at 09:41, Vincent Massol<vincent(a)massol.net>
>> wrote:
>>>
>>> On Jul 4, 2009, at 2:44 PM, tmortagne (SVN) wrote:
>>>
>>>> Author: tmortagne
>>>> Date: 2009-07-04 14:44:30 +0200 (Sat, 04 Jul 2009)
>>>> New Revision: 21811
>>>>
>>>> Modified:
>>>> Â platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>>>> Document.java
>>>> Â platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>>>> XWiki.java
>>>> Â platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/doc/
>>>> XWikiDocument.java
>>>> Â platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/api/
>>>> XWikiTest.java
>>>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml
>>>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>>>> java/org/xwiki/rendering/internal/renderer/
>>>> DefaultPrintRendererFactory.java
>>>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>>>> java/org/xwiki/rendering/parser/Syntax.java
>>>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>>>> java/org/xwiki/rendering/parser/SyntaxType.java
>>>> Â platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/main/
>>>> java/org/xwiki/rendering/renderer/PrintRendererFactory.java
>>>> Â platform/web/trunk/standard/src/main/webapp/templates/
>>>> contentview.vm
>>>> Â platform/web/trunk/standard/src/main/webapp/templates/plain.vm
>>>> Log:
>>>> XWIKI-4042: Add a way to choose the renderer when viewing a page
>>>
>>>>
>>>> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/
>>>> xwiki/
>>>> api/Document.java
>>>> ===================================================================
>>>> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>>>> Document.java 2009-07-04 12:42:14 UTC (rev 21810)
>>>> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>>>> Document.java 2009-07-04 12:44:30 UTC (rev 21811)
>>>> @@ -37,6 +37,7 @@
>>>> import org.suigeneris.jrcs.diff.DifferentiationFailedException;
>>>> import org.suigeneris.jrcs.diff.delta.Delta;
>>>> import org.suigeneris.jrcs.rcs.Version;
>>>> +import org.xwiki.rendering.parser.Syntax;
>>>>
>>>> import com.xpn.xwiki.XWiki;
>>>> import com.xpn.xwiki.XWikiContext;
>>>> @@ -473,6 +474,16 @@
>>>> Â Â }
>>>>
>>>> Â Â /**
>>>> + Â Â * @param targetSyntax the syntax in which render the document
>>>> content
>>>> + Â Â * @return the rendered content
>>>> + Â Â * @throws XWikiException error when rendering content
>>>> + Â Â */
>>>> + Â Â public String getRenderedContent(Syntax targetSyntax) throws
>>>> XWikiException
>>>> + Â Â {
>>>> + Â Â Â Â return this.doc.getRenderedContent(targetSyntax,
>>>> getXWikiContext());
>>>> + Â Â }
>>>
>>> Since this is for Velocity, isn't it better to use a syntax Id String
>>> instead of a Syntax object which is hard to construct from velocity?
>>
>> The problem is that it was not easy to find a right signature since
>> there is already getRenderedContent taking string fo the parser
>> syntax. Since anyway it's necessary to give a supported syntax by
>> looking at existing one it was easier to not have to directly give the
>> found valid syntax object.
>>
>>>
>>>> +
>>>> + Â Â /**
>>>> Â Â Â * return a escaped version of the content of this document
>>>> Â Â Â */
>>>> Â Â public String getEscapedContent() throws XWikiException
>>>>
>>>> Modified: platform/core/trunk/xwiki-core/src/main/java/com/xpn/
>>>> xwiki/
>>>> api/XWiki.java
>>>> ===================================================================
>>>> --- platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>>>> XWiki.java   2009-07-04 12:42:14 UTC (rev 21810)
>>>> +++ platform/core/trunk/xwiki-core/src/main/java/com/xpn/xwiki/api/
>>>> XWiki.java   2009-07-04 12:44:30 UTC (rev 21811)
>>>> @@ -30,6 +30,8 @@
>>>> import org.apache.commons.logging.LogFactory;
>>>> import org.suigeneris.jrcs.diff.delta.Chunk;
>>>> import org.xwiki.query.QueryManager;
>>>> +import org.xwiki.rendering.parser.Syntax;
>>>> +import org.xwiki.rendering.renderer.PrintRendererFactory;
>>>>
>>>> import com.xpn.xwiki.XWikiContext;
>>>> import com.xpn.xwiki.XWikiException;
>>>> @@ -2685,4 +2687,42 @@
>>>> Â Â {
>>>> Â Â Â Â return this.xwiki.getDefaultDocumentSyntax();
>>>> Â Â }
>>>> +
>>>> + Â Â /**
>>>> + Â Â * Find the corresponding available renderer syntax.
>>>> + Â Â * <p>
>>>> + Â Â * If <code>syntaxVersion</code> is null the last version of
>>>> the available provided syntax type is returned.
>>>> + Â Â *
>>>> + Â Â * @param syntaxType the syntax type
>>>> + Â Â * @param syntaxVersion the syntax version
>>>> + Â Â * @return the available corresponding {@link Syntax}. Null if
>>>> no available renderer can be found.
>>>> + Â Â */
>>>> + Â Â public Syntax getAvailableRendererSyntax(String syntaxType,
>>>> String syntaxVersion)
>>>> + Â Â {
>>>> + Â Â Â Â Syntax syntax = null;
>>>> +
>>>> + Â Â Â Â PrintRendererFactory printRendererFactory =
>>>> + Â Â Â Â Â Â (PrintRendererFactory)
>>>> Utils.getComponent(PrintRendererFactory.class);
>>>> +
>>>> + Â Â Â Â List<Syntax> availableSyntaxes =
>>>> printRendererFactory.getAvailableSyntaxes();
>>>
>>> We already have the notion of available syntaxes in the
>>> SyntaxFactory.
>>
>> No, we have the notion of available parsers, the method name is just
>> wrong in SyntaxFactory... The only place where we know the available
>> renderers is the PrintRendererFactory since it's impossible to get all
>> renderers otherwise until renderer are made components.
>>
>>> I don't understand why we need to have them in the
>>> PrintRendererFactory (which is not supposed to return syntaxes BTW,
>>> it's only supposed to return PrintRenderer(s).
>>>
>>>> +
>>>> + Â Â Â Â for (Syntax availableSyntax : availableSyntaxes) {
>>>
>>> Why not instead do:
>>> SyntaxType syntaxType = SyntaxType.getSyntaxType(syntaxTypeAsString);
>>>
>>> And then (when syntaxVersion != null):
>>> Syntax syntax = new Syntax(syntaxType, syntaxVersion);
>>>
>>> And then:
>>> syntaxFatory.getAvailableSyntaxes().contains(syntax)
>>
>> It's not that simple since we have to support the use case where
>> syntaxVersion is not given (which is most of the time).
>>
>>>
>>> hmmm.... Actually thinking more about it, I believe this whole code
>>> should be moved out of XWikiDocument and instead go in the rendering
>>> module in SyntaxFactory.
>>
>> Again in SyntaxFactory you have no idea what are the available
>> renderers syntaxes and here we don't care about parsers.
>> Until we have clean renderer componet my goal was to put as less as
>> possible temporary code in rendering module.
>>
>>>
>>>> + Â Â Â Â Â Â if (syntaxVersion != null) {
>>>> + Â Â Â Â Â Â Â Â if
>>>> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType)
>>>> + Â Â Â Â Â Â Â Â Â Â &&
>>>> availableSyntax.getVersion().equals(syntaxVersion)) {
>>>> + Â Â Â Â Â Â Â Â Â Â syntax = availableSyntax;
>>>> + Â Â Â Â Â Â Â Â Â Â break;
>>>> + Â Â Â Â Â Â Â Â }
>>>> + Â Â Â Â Â Â } else {
>>>> + Â Â Â Â Â Â Â Â // TODO: improve version comparaison since it does
>>>> not work when comparing 2.0 and 10.0 for example. We
>>>> + Â Â Â Â Â Â Â Â // should have a Version which implements
>>>> Comparable like we have SyntaxId in Syntax
>>>> + Â Â Â Â Â Â Â Â if
>>>> (availableSyntax.getType().toIdString().equalsIgnoreCase(syntaxType)
>>>> + Â Â Â Â Â Â Â Â Â Â && (syntax == null ||
>>>> availableSyntax.getVersion().compareTo(syntax.getVersion()) > 0)) {
>>>> + Â Â Â Â Â Â Â Â Â Â syntax = availableSyntax;
>>>> + Â Â Â Â Â Â Â Â }
>>>> + Â Â Â Â Â Â }
>>>> + Â Â Â Â }
>>>> +
>>>> + Â Â Â Â return syntax;
>>>> + Â Â }
>>>> }
>>>
>>> [snip]
>>>>
>>>> Â Â /**
>>>> + Â Â * @return the syntax of the document
>>>> + Â Â */
>>>> + Â Â private Syntax getSyntax()
>>>> + Â Â {
>>>> + Â Â Â Â Syntax syntax = null;
>>>> +
>>>> + Â Â Â Â String syntaxId = getDefaultDocumentSyntax();
>>>> + Â Â Â Â try {
>>>> + Â Â Â Â Â Â syntax =
>>>> this.syntaxFactory.createSyntaxFromIdString(getSyntaxId());
>>>
>>> Shouldn't we save the Syntax object instead of syntaxId in
>>> XWikiDocument so that we don't perform the conversion every time
>>> getSyntax is called?
>>
>> I did not planed to refactor the whole XWikiDocument, i just done what
>> was needed but at some point yes we should have Syntax and XDOM
>> instead of the syntax/content strings :)
>>
>>>
>>>> + Â Â Â Â } catch (ParseException e) {
>>>> + Â Â Â Â Â Â LOG.error("Failed to genrate Syntax object for syntax
>>>> identifier [" + syntaxId + "] in page ["
>>>
>>> Typo: generate
>>>
>>>> + Â Â Â Â Â Â Â Â + getDocumentName() + "]", e);
>>>> +
>>>> + Â Â Â Â Â Â syntaxId = getDefaultDocumentSyntax();
>>>
>>> I don't understand this line above, it's the same as the one a few
>>> lines above.
>>>
>>>> + Â Â Â Â Â Â try {
>>>> + Â Â Â Â Â Â Â Â syntax =
>>>> this
>>>> .syntaxFactory.createSyntaxFromIdString(getDefaultDocumentSyntax());
>>>
>>> It seems you're not using the syntaxId variable.
>>
>> Yes it's an error, I added the variables when added the error message
>> and forgot to change the "real" code properly.
>>
>>>
>>>> + Â Â Â Â Â Â } catch (ParseException e1) {
>>>> + Â Â Â Â Â Â Â Â LOG.error("Failed to genrate default Syntax object.
>>>> The defautlt syntax id in [" + syntaxId + "]", e);
>>>
>>> same typo
>>>
>>> [snip]
>>>
>>>> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/
>>>> pom.xml
>>>> ===================================================================
>>>> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml
>>>> 2009-07-04 12:42:14 UTC (rev 21810)
>>>> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/pom.xml
>>>> 2009-07-04 12:44:30 UTC (rev 21811)
>>>> @@ -187,7 +187,9 @@
>>>> Â Â Â Â Â Â Â Â <!-- Excludes for the 2.0 M2 release. Once it's
>>>> released remove them. -->
>>>> Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/MacroManager</
>>>> exclude>
>>>> Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/MacroSource</
>>>> exclude>
>>>> - Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/
>>>> AbstractMacroSource</exclude>
>>>> + Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/macro/
>>>> AbstractMacroSource</exclude>
>>>> + Â Â Â Â Â Â Â Â <!-- Seems clirr plugin consider adding new API as
>>>> an error (which I don't understand). -->
>>>
>>> It doesn't normally (it' considered as an INFO level) unless it
>>> breaks
>>> binary compatibility. But I don't know why in your case (would need
>>> to
>>> check more the code, i'm only looking at the svn diff).
>>
>> If you remove this the plugin clearly say that there is an error and
>> it also clearly say that the error is that there is new api in
>> PrintRendererFactory. Maybe the error message is wrong but i check and
>> rechecked and this is the only difference.
>>
>>>
>>>> + Â Â Â Â Â Â Â Â <exclude>org/xwiki/rendering/renderer/
>>>> PrintRendererFactory</exclude>
>>>> Â Â Â Â Â Â Â </excludes>
>>>> Â Â Â Â Â Â </configuration>
>>>> Â Â Â Â Â </execution>
>>>>
>>>> Modified: platform/core/trunk/xwiki-rendering/xwiki-rendering-api/
>>>> src/main/java/org/xwiki/rendering/internal/renderer/
>>>> DefaultPrintRendererFactory.java
>>>> ===================================================================
>>>> --- platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/
>>>> main/
>>>> java/org/xwiki/rendering/internal/renderer/
>>>> DefaultPrintRendererFactory.java    2009-07-04 12:42:14 UTC (rev
>>>> 21810)
>>>> +++ platform/core/trunk/xwiki-rendering/xwiki-rendering-api/src/
>>>> main/
>>>> java/org/xwiki/rendering/internal/renderer/
>>>> DefaultPrintRendererFactory.java    2009-07-04 12:44:30 UTC (rev
>>>> 21811)
>>>> @@ -19,6 +19,10 @@
>>>> Â */
>>>> package org.xwiki.rendering.internal.renderer;
>>>>
>>>> +import java.util.Arrays;
>>>> +import java.util.Collections;
>>>> +import java.util.List;
>>>> +
>>>> import org.xwiki.component.annotation.Component;
>>>> import org.xwiki.component.annotation.Requirement;
>>>> import org.xwiki.rendering.parser.Syntax;
>>>> @@ -43,6 +47,10 @@
>>>> @Component
>>>> public class DefaultPrintRendererFactory implements
>>>> PrintRendererFactory
>>>> {
>>>> + Â Â private static final List<Syntax> AVAILABLE_SYNTAXES =
>>>> +
>>>> Collections.unmodifiableList(Arrays.asList(Syntax.XHTML_1_0,
>>>> Syntax.XWIKI_2_0, Syntax.EVENT_1_0,
>>>> + Â Â Â Â Â Â Syntax.TEX_1_0, Syntax.PLAIN_1_0));
>>>
>>> I don't like this, see above.
>>
>> Again it's a factory, it's the only place where we really now what are
>> the renderers. I don't like this either but since renderer are not
>> component there is no choice.
>>
>>>
>>>> +
>>>> Â Â /**
>>>> Â Â Â * Factory to easily create an XHTML Image and Link Renderers.
>>>> Â Â Â */
>>>> @@ -55,6 +63,16 @@
>>>> Â Â /**
>>>> Â Â Â * {@inheritDoc}
>>>> Â Â Â *
>>>> + Â Â * @see
>>>> org
>>>> .xwiki
>>>> .rendering.renderer.PrintRendererFactory#getAvailableSyntaxes()
>>>> + Â Â */
>>>> + Â Â public List<Syntax> getAvailableSyntaxes()
>>>> + Â Â {
>>>> + Â Â Â Â return AVAILABLE_SYNTAXES;
>>>> + Â Â }
>>>> +
>>>
>>> I don't like this, see above.
>>>
>>> [snip]
>>>
>>> Thanks
>>> -Vincent
>>>
>>> _______________________________________________
>>> devs mailing list
>>> devs(a)xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>
>>
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
On Jul 9, 2009, at 12:15 PM, tmortagne (SVN) wrote:
> Author: tmortagne
> Date: 2009-07-09 12:15:53 +0200 (Thu, 09 Jul 2009)
> New Revision: 21863
>
> Modified:
> platform/xwiki-plugins/trunk/wiki-manager/src/main/java/com/xpn/
> xwiki/plugin/wikimanager/WikiManagerException.java
> Log:
> [misc] Add serialize id
>
> Modified: platform/xwiki-plugins/trunk/wiki-manager/src/main/java/
> com/xpn/xwiki/plugin/wikimanager/WikiManagerException.java
> ===================================================================
> --- platform/xwiki-plugins/trunk/wiki-manager/src/main/java/com/xpn/
> xwiki/plugin/wikimanager/WikiManagerException.java 2009-07-09
> 09:56:02 UTC (rev 21862)
> +++ platform/xwiki-plugins/trunk/wiki-manager/src/main/java/com/xpn/
> xwiki/plugin/wikimanager/WikiManagerException.java 2009-07-09
> 10:15:53 UTC (rev 21863)
> @@ -30,11 +30,6 @@
> public class WikiManagerException extends PluginException
> {
> /**
> - * Serialize id.
> - */
> - private static final long serialVersionUID =
> -6451750749104331619L;
> -
> - /**
> * Error when trying to use provided user that does not exists.
> * <p>
> * TODO : move in XWikiException
> @@ -98,6 +93,11 @@
> // //////
>
> /**
> + * Serialize id.
> + */
> + private static final long serialVersionUID =
> -6451750749104331619L;
> +
I've asked myself several times how to document this. I've used
different versions:
- "Unique ID for Class Serialization."
- "Class id for Serialization."
and the more descriptive:
/**
* Needed to identify the version of this code when serializing/
deserializing (since Exception is Serializable).
* Note that the value needs to be modified whenever a non
transient field is added or removed in this class.
*/
The last one is the one I prefer (I think) since not everyone knows
about this and it makes it clear that the id needs to be modified
whenever a new field is added/removed.
We could also add a link to some URL describing class serialization.
WDYT?
Thanks
-Vincent