Hello fellow developers,
I am working on upgrading our core, based on xwiki 1.5.4 to xwiki 3.2. Quite a jump.
Among the least jump, velocity seems to have jumped from version 1.5 to version 1.7.
Nonetheless, this seems to cause a surprising effect: while macros could redefine the value of parameters they were passed, and that change was honoured after the macro, they cannot anymore.
The following script:
> #macro(redefine $var)
> #set($var="redefined")
> #end
>
> #set($x="original")
>
> x is $x
>
> #redefine($x)
>
> x is $x
gives the following output in a new core:
> x is original
>
> x is original
>
and the following in our old core:
> x is original
>
> x is redefined
>
This has all sorts of consequences including such macros as the navigation not receiving the result of normalizelink...
Did I miss an optional parameter of velocity to revert to the old method?
paul
Hi devs,
Since I plan to move some stuff from platform to commons I would like
to know what you think of the history in this case.
Pros including history:
* can access easily the whole history of a moved file. But sometimes
changing packages etc make too much difference for git to see it's
actually the same file so you loose it anyway.
Cons including history:
* double the history which make tools like ohloh indicate wrong informations
* it's a lot easier to move without history
WDYT ?
Even if it was looking a bit weird to me at first I'm actually +1 to
not move the history in this case.
Eduard was proposing to include in the first commit of the new
repository the id of the last commit containing the files (basically
the id of the parent of the commit deleting the files) in the old
repository so that it's easier to find it. I'm +1 for this.
--
Thomas Mortagne
Hi devs,
XWiki is planning to participate in this year's Google Summer of Code [1].
The organization registration period has already started and the deadline
is the 9th of March [2] (a bit more than one week).
1. We need to provide by then a list of proposals and assign mentors for
the students that are going to implement them.
I would like to ask everybody that wants to participate as a mentor from
the XWiki organization to review the proposals [3] list (that is currently
empty) and add as many interesting proposals as possible.
The proposals can be either new, or they can be revived from previous year
proposals. Just navigate to the previous years, find the proposal you like
and know about, go to its proposal page (click it) and press the "Clone to
this year" link. Now you can assign yourself as lead for that project,
update it's description if needed and wait for the student applications to
start pouring :)
2. We also need to submit the actual application [4] of the XWiki
organization to participate to the GSoC 2012 project so I would also like
to ask you to review it so that we have a better chance of being selected
into the program.
Thanks for your help,
Eduard
----------
[1] http://www.google-melange.com/gsoc/homepage/google/gsoc2012
[2] http://www.google-melange.com/gsoc/events/google/gsoc2012
[3]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HProposedProjects28…
[4]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/OrganizationApplicat…
Hi devs,
Right now renaming a key is a pain if we don't want to loose the
existing translations associated to it. Basically it require to rename
the key in all languages and reimport all of them on l10n.xwiki.org.
We already have a section in the translation file to indicate which
translations are deprecated. The idea is to indicate what is the new
name of a deprecated translation key directly in the translation file
so that l10n.xwiki.org can automatically copy the translation to the
new key when it find a new deprecated key while importing default
translation file.
For that we need to decide a syntax to indicate what is the new name of the key.
I propose to do something similar to java and indicate it in a comment
like the following:
new.key.name=Default translation
#@deprecated new.key.name
old.key.name=Default translation
Here are some other alternatives to "deprecated":
* replacedBy
* new
others ?
Here is my +1 for "deprecated", more intuitive for Java developers and
it's clear it's a deprecated translation key.
Thanks,
--
Thomas Mortagne
Hi devs,
>From the start Extension Manager has been designed to be usable
outside of XWiki. I would like to make this effective by moving it
into commons.
Here is the detail of the operation:
= Not moved
* UI of Extension Manager
* Xar handler
* Server side module and UI of XWiki Repository (but the client will
be moved to commons since a generic REST protocol has been designed
for it which could be implemented by anything)
* Clustering module
* Script service module
* An ExecutionContextInitializer which is responsible for switching
the current Thread classloader for each new request with the one
linked to the current wiki (so that everything loading classes like
script macros do it from the proper classloader)
That means that the commons version of Extension Manager will support
everything the current one supports except for the thing that don't
make sense outside of XWiki (XAR packages, wiki pages UI, etc.).
= Dependencies to move
* ClassLoader module: even more than Extension Manager (and like other
stuff that will follow in other mails) this module is ready to be
moved as it is except for the attachment based support which is
already in a separated module and will stays in platform obviously.
= Extracted from Extension Manager
* Job Manager: encapsulate background task into a job providing
progress and status informations as well as logging isolation. In it's
own module.
* ClassLoader Manager: namespace based organization for classloaders
(like we have for Component Managers). In the existing classloader
module.
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi Devs,
I would like to commit the following change on the internal API of the
hibernate store:
Deprecate
public boolean beginTransaction(boolean withTransaction, XWikiContext
context)
public boolean beginTransaction(SessionFactory sfactory, boolean
withTransaction, XWikiContext context)
in favor of
public boolean beginTransaction(SessionFactory sfactory, XWikiContext
context)
Deprecate
public void endTransaction(XWikiContext context, boolean commit,
boolean withTransaction)
public <T> T execute(XWikiContext context, boolean bTransaction,
boolean doCommit, HibernateCallback<T> cb)
in favor of
public <T> T execute(XWikiContext context, boolean doCommit,
HibernateCallback<T> cb)
and add new method
public <T> T failSafeExecute(XWikiContext context, boolean doCommit,
HibernateCallback<T> cb)
Deprecate
public <T> T executeRead(XWikiContext context, boolean bTransaction,
HibernateCallback<T> cb) throws XWikiException
in favor of
public <T> T executeRead(XWikiContext context, HibernateCallback<T> cb)
throws XWikiException
and add new method
public <T> T executeFailSafeRead(XWikiContext context,
HibernateCallback<T> cb)
Deprecate
public <T> T executeWrite(XWikiContext context, boolean bTransaction,
HibernateCallback<T> cb)
in favor of
public <T> T executeWrite(XWikiContext context, HibernateCallback<T>
cb) throws XWikiException
and add new method
public <T> T failSafeExecuteWrite(XWikiContext context,
HibernateCallback<T> cb)
My motivation:
- reduce confusion, since the current signature let you think that
sub-transaction are possible, and these are not, since the withTransaction
argument is unused.
- provide an easy way to run potentially failing transaction, that will
not do logging and neither throw. It is the responsability of the caller to
manager the situation.
The later could be use to easily check the state of the database during a
migration for example. Is a table exists ? is column exists ? could be done
by simple fail safe selection, if these fail, you are almost sure the table
or column is missing.
Anything against these changes ?
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
For xwiki-platform in https://github.com/xwiki/xwiki-platform , no matter which branch I choose, I always got the 4.0-snapshot ,How can I get a stable one ? Thanks for helping me. Could express my thanks in this way ?I'm sorry my Englist is poor .
Hi,I want to download the code of stable-3.5 version from https://github.com/xwiki ,but they're all snapshop-3.5 version which is shown in pom.xml ,why? Is it ok?
Right now on an empty wiki you have all the rights except "delete"
(and register).
So this means that you have "admin" right but you don't have "delete" rights...
This does not make much sense and I anyway I don't see why delete has
this special rule.
Any idea ?
Here is my +1 to remove the special handling of "delete" default right.
--
Thomas Mortagne