On Tue, Jul 14, 2009 at 09:13, Vincent Massol<vincent(a)massol.net> wrote:
>
> On Jul 14, 2009, at 8:11 AM, Marius Dumitru Florea wrote:
>
>> Vincent Massol wrote:
>>> Hi Thomas,
>>>
>>> On Jul 13, 2009, at 3:20 PM, tmortagne (SVN) wrote:
>>>
>>>> Author: tmortagne
>>>> Date: 2009-07-13 15:20:03 +0200 (Mon, 13 Jul 2009)
>>>> New Revision: 21910
>>
>> [snip]
>>
>>>> public void testIncludeMacroWithNewContext() throws Exception
>>>> {
>>>> - String expected = "beginDocument\n"
>>>> - + "beginMacroMarkerStandalone [velocity] [] [$myvar]\n"
>>>> - + "beginParagraph\n"
>>>> - + "onWord [hello]\n"
>>>> - + "endParagraph\n"
>>>> - + "endMacroMarkerStandalone [velocity] [] [$myvar]\n"
>>>> - + "endDocument";
>>>> + String expected =
>>>> + "beginDocument\n" + "beginMacroMarkerStandalone
>>>> [velocity] [] [$myvar]\n" + "beginParagraph\n"
>>>> + + "onWord [hello]\n" + "endParagraph\n" +
>>>> "endMacroMarkerStandalone [velocity] [] [$myvar]\n"
>>>> + + "endDocument";
>>>
>>> I much prefer my version. Can you please rollback? Again an example
>>> why applying code style automatically sucks :)
>>
>> Why don't you use a StringBuffer?
>
> It's more clear this way (and btw performance wise it's better - see
> my other mail in response to you).
>
> [snip]
>
>>>> IncludeMacro macro = (IncludeMacro)
>>>> getComponentManager().lookup(Macro.class, "include");
>>>>
>>>> mockDocumentAccessBridge
>>>> .expects
>>>> (once()).method("isDocumentViewable").will(returnValue(true));
>>>> @@ -119,7 +120,7 @@
>>>>
>>>> assertBlocks(expected, blocks);
>>>> }
>>>> -
>>>> +
>>>> public void testIncludeMacroWithNoDocumentSpecified() throws
>>>> Exception
>>>> {
>>>> IncludeMacro macro = (IncludeMacro)
>>>> getComponentManager().lookup(Macro.class, "include");
>>>> @@ -129,8 +130,8 @@
>>>> macro.execute(parameters, null, new
>>>> MacroTransformationContext());
>>>> fail("An exception should have been thrown");
>>>> } catch (MacroExecutionException expected) {
>>>> - assertEquals("You must specify a 'document' parameter
>>>> pointing to the document to include.",
>>>> - expected.getMessage());
>>>> + assertEquals("You must specify a 'document' parameter
>>>> pointing to the document to include.", expected
>>>> + .getMessage());
>>>
>>> again a brilliant example why it sucks... :(
>>
>> Can you store the long string in a separate variable (maybe a
>> StringBuffer if it's really long)?
>
> Marius, I see where you want to go but this will never work. You can't
> modify code so that automatic formatting will always be perfect. If we
> want to automate formatting (like with a SVN hook to automatically
> apply code style - in a first commit for ex) then we'll have to accept
> suboptimal result. The balance of course is vs wrongly formatted code
> which is probably more the norm in our code in general.
>
> I'm just whinning because I'm very strict with my code style and I
> directly format it in a certain way that I find the best and the IDE
> formatting removes my carefully crafted styles... ;)
I usually take care of respecting format in unit tests, i added last
minutes unit tests and forgot it.
For the "runtime code" it's usually more important for me to be sure
the code is always the same for everyone than to have lots of custom
style everywhere. Using Eclipse formater make a lots quicker and
easier to respect the checkstyle and there is not that much use cases
where it's an issue.
>
> If we could improve the IDE styles it could be ok. But I don't think
> Eclipse for ex support things like:
> - put braces on next line for if/for/etc only if the line is longer
> than 120 chars. We could also decide to remove this rule we had voted
> and (which I personally like - my preference has always been braces on
> next line everywhere for increased readability)
I would prefer choosing having the braces on next line (note i was not
here for this vote) than saing it's impossible to use Eclipse
formatter.
> - don't split on "." (as in the example above)
I quickly looked and Eclipse formatter support this very well when you
configure it.
> - don't split for javadoc @see (to be verified this is invalid - I
> seem to recall it is)
Javadoc is splited only when it's longer than 120 characters so there
is no issue
>
>
> Thanks
> -Vincent
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
On Jul 14, 2009, at 11:06 PM, Sergiu Dumitriu (JIRA) wrote:
> More significant HTTP status codes for error responses
> ------------------------------------------------------
>
> Key: XWIKI-4089
> URL: http://jira.xwiki.org/jira/browse/XWIKI-4089
> Project: XWiki Core
> Issue Type: Improvement
> Components: Actions and URLs
> Affects Versions: 2.0 M1
> Reporter: Sergiu Dumitriu
>
>
> Several error messages come with the default 200 HTTP status code,
> indicating success, although the request did not complete normally.
> Besides adding more semantics, this is also more friendly with
> services and AJAX calls.
>
> - access denied -> 403 Forbidden
> - document locked -> 423 Locked
> - invalid action on non-existing document -> 404 Not Found
> - invalid action on wrong document -> 400 Bad Request
> - invalid target for copy and rename -> 409 Conflict
> - template does not exist -> 400 Bad Request
Won't we get default browser error pages instead of our own error pages?
Thanks
-Vincent
The BlogPostSheet contains this line:
#template('tagedit.vm')
which in turn contains a HTML comment (<!-- ... -->) which is turned into this: <!<del> ... </del>>
Is there a way to load the template in a 2.0 syntax without having this conversion.
The BlogPostSheet was wrapped this way (done by the 1.0 to 2.0 Converter):
{{velocity filter="none"}}
{{html clean="false" wiki="true"}}
...
Thanks
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
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