Hi
Doing a build today I saw that it is problem in the xwiki-core/pom.xml updated by you. It is a case of a missing S at the end of xwiki-core-rendering-macro-footnote(s).
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
Hi
As the last items on the Blog 2.0 Upgrade I wanted to upgrade the RSS documents like GlobalBlogRss. There I ran into the issue that the renderer (I don't know which) is adding the macro as comment to the beginning of the XML file but that is not allowed because the <?xml must start the file (not even spaces are allowed). The upgrade code looks like this:
{{include document="Blog.RssCode"/}}
{{velocity filter="none"}}
{{html clean="false" wiki="true"}}
##
##
##
#getGlobalBlogEntries($entries)
#set($entries = $xwiki.wrapDocs($entries))
#displayGlobalBlogRss($entries)
{{/html}}
{{/velocity}}
The page output looks like this:
<!--startmacro:include|-|document="Blog.RssCode"--><!--stopmacro--><!--startmacro:velocity|-|filter="none"|-|
{{html clean="true" wiki="true"}}
##
##
##
#getGlobalBlogEntries($entries)
#set($entries = $xwiki.wrapDocs($entries))
#displayGlobalBlogRss($entries)
{{/html}}
--><p> <?xml version="1.0" encoding="UTF-8" ?>
Does anyone know how to remove that comment or how to generate proper XML content with 2.0? If anyone can point me to some code that does that would be enough to get me started.
Cheers - Andy
Hi devs,
I'm currently working on a network event distribution system.
The goal is to be able to shared events across XWiki instance (or not
XWiki) of a same network groups.
There is two target:
- unique easy clustering channel: if every XWiki instance of a network
group share the events it's becoming easy to make sure all instance of
the same cluster are synchronized and not only the code which is using
default cache system
- a new push communication interface to know what append on a farm for
network administrator or for softs like XWord and XEclipse to easily
update pages list etc...
To summarize I plan to do a Remote Observation Manager module which
send events coming for Observation Manager and inject in it events
coming for the network.
See http://dev.xwiki.org/xwiki/bin/view/Design/DistributedEvents for
more details (like events converters etc...).
For now my choice is on jgroups for the network part which is simple
to use, very configurable and well known. I looked at some other like
JMS or Hazelcast but after all, I think jgroups contains all i need
and is very light.
Would be great if some of you who has experience on this (or not)
could shoot with all remarks and suggestions.
I should be able to commit a first try based on jgroups this week on sandbox.
Thanks,
--
Thomas Mortagne
Hi devs,
We are more than two weeks late already and 2.0M2 is finally is a
stable enough state to be released.
Note that it 68 jira issues has been closed since 2.0M1.
Here is my +1.
--
Thomas Mortagne
+1
JV.
On Thu, Jul 30, 2009 at 10:55 AM, Jean-Vincent Drean<jvdrean(a)gmail.com> wrote:
> +1
>
> JV.
>
> On Wed, Jul 29, 2009 at 8:02 PM, Thomas
> Mortagne<thomas.mortagne(a)xwiki.com> wrote:
>> Hi devs,
>>
>> We are more than two weeks late already and 2.0M2 is finally is a
>> stable enough state to be released.
>>
>> Note that it 68 jira issues has been closed since 2.0M1.
>>
>> Here is my +1.
>>
>> --
>> Thomas Mortagne
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
I am close to have the entire Blog Application upgraded to 2.0 Syntax (now I upgraded the Panels). That brings me back to the create an export of the application which is a pain in the next using the full export but does not work using the Import / Export Application.
Looking into the I/E App I saw that it is using XWiki.searchDocuments(String sql) but that will not return any HIDDEN documents. The PackageAPI (used by the full export) is not providing a list and it seems it would break its indention to do so.
So first I was wondering if there is a way to obtain a list of documents including the hidden ones?
I not then I was wondering if we should export XWiki or should create another Plugin that delivers all documents?
Finally I am thinking that we might should extend the full export (XWiki Administration) allowing a user to create custom exports more or less like the I/E application?
Cheers - Andy
(resending since I got a failure from xwiki's mail content filter )
---------- Forwarded message ----------
From: Vincent Massol <vincent(a)massol.net>
Date: Sun, Jul 26, 2009 at 11:33 AM
Subject: [Wiki Importer] Design questions
To: XWiki Developers <devs(a)xwiki.org>
Hi Arun,
I've just started reviewing your module. I'll send questions as they
come. Here are some to start with:
1) Â Why do you need the Wiki interface? Since all implementations are
wiki-specific and since it doesn't contain any useful method I don't
see why it's needed.
2) Â Why do you need 2 methods in WikiImporter interface? I would have
imagine only a single method:
WikiImporter.import(...)
3) Why do you pass a byte array instead of a stream? If the import is
large a byte array will result in an OOM error.
4) WikiImporterVelocityContextInitializer has invalid javadoc. In
addition instead of exposing each importer you could expose only a
single importer factory and pass an import syntax to it. This will
reduce the coupling and not expose the implementations to the client
side (very important). Something like:
WikiImporterFactory.createImporter(ImportSyntax).
5) This should never be written (in DefaultImportWikiParser &
DefaultImportWikiRenderer for ex):
    //Intialize Embeddable Component Manager
    EmbeddableComponentManager ecm = new EmbeddableComponentManager();
    ecm.initialize(this.getClass().getClassLoader());
The component manager must alway be passed as a dependency.
6) You shouldn't use @Component("default") but instead @Component
7) You should never use  new
File(System.getProperty("java.io.tmpdir"). Instead you should use the
existing API located in
Container.getApplicationContext().getTemporaryDirectory().
I have some more comments but since they are linked to the above let's
agree first on the points above before going further.
Thanks
-Vincent
Hi Devs,
Currently on a multi-xwiki installation all the xwikis can manipulate the OO
server instance shared between them. I think it makes more sense to allow
only the primary xwiki to control the oo server while rest of the xwikis
become observers / consumers.
WDYT?
Here is my +1.
Thanks.
- Asiri