On Thu, Dec 23, 2010 at 3:41 PM, Ludovic Dubost <ludovic(a)xwiki.com> wrote:
>
> Hi,
>
> We have a general problem when upgrading XWiki which is to not forget to
> exclude certain files from the import.
> The manual exclusion is something that generates all sorts of problems
> especially when done by less experienced users.
>
> These files are:
>
> - preferences
> - all and admin group
> - admin user
> - invitation config file
> - anotation config file
>
> Either we make a FULL and an UPGRADE XAR or we make a CODE and CONFIG xar
> (initial install would need both xars to be imported).
We can also do : CODE, CONFIG and FULL that is the sum of both.
+1 for the idea, that will makes our and those of our users easier
until we have a proper upgrade mechanism with the EM
Jerome.
>
> I'm more for the solution of one FULL and one UPGRADE xar.
>
> Ludovic
>
> --
> Ludovic Dubost
> Blog: http://blog.ludovic.org/
> XWiki: http://www.xwiki.com
> Skype: ldubost GTalk: ldubost
>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
Hi developers,
Ludovic recently raised the fact that custom displayers stopped
working as expected with syntax 2.0 (the scripts cannot access the
standard bindings).
Ludovic also proposes a patch : see
http://jira.xwiki.org/jira/browse/XWIKI-4904. While I don't really
measure all impact of the patch, I think replacing XWiki#parseContent
by syntax rendering can only be a good thing.
Any other opinions ?
OK to commit in 2.7 ?
Jerome.
Hi devs,
today XWiki Watch is a top level project, toplevel in the svn and listed
on the main page of xwiki.org.
I propose we downgrade it to extension status and move its code
appropriately, somewhere in the plugins and applications. Along with
this, the standalone distribution (and installers) would also be removed.
The reason for this is that it makes more sense as an extension than a
toplevel project (it's an extra feature that you can add to XWiki by
installing an application and deploying a couple of jars), and also
because it has been on the backburner lately, and there is no roadmap to
make a fully featured toplevel product of it.
Also, according to this vote
http://xwiki.markmail.org/thread/scrwsfqfm6b5h5zf I would like to
release something from the current trunk (1.1M2 probably), compatible
with a latest XWiki.
I'm +1 for all these.
WYDT?
Thanks,
Anca
I have written a gwt servlet which I could successfully use in a gwt client
inserted through a component into a xwiki page. I now wonder how I can check
user authentication from the gwt servlet, since even though I can lookup
other components, the context variables are empty.
thanks
Vito Impagliazzo
I would like to deprecate the following methods because they insert and remove content which is
dependent on JRCS for parsing and generation:
XWikiAttachmentArchive#getArchive()
XWikiAttachmentArchive#getArchive(XWikiContext)
XWikiAttachmentArchive#setArchive(byte[])
These are not easily removed because they are needed for the packaging plugin but I think we should
move away from that means of import/export as it contains code (including JRCS) which is memory
inefficient.
Also in the 3.0 cycle, I would like to make private the following methods from XWikiHibernateStore
as they are not used externally and are currently deprecated:
loadXWikiProperty
saveXWikiClass
loadXWikiClass
loadAttachmentList
saveAttachmentList
saveAttachment
injectCustomMappingsInSessionFactory
injectInSessionFactory
isValidCustomMapping
I would like to remove the following methods entirely as they are also deprecated and are not used
at all:
getBatcherStats
resetBatcherStats
deleteXWikiClass
saveXWikiClassProperty
WDYT?
Caleb