26 Apr
2016
26 Apr
'16
9:05 a.m.
That still require programming right :)
The best would be to have a helper for XAR extensions in the core.
Something like a specific wiki listener which allow safely listen to
some events without the need for programming right.
On Tue, Apr 26, 2016 at 12:27 AM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Well, I guess that if a XAR extension needs to migrate
its data, it will
have to depend on some jar extension that will have the migration code and
that will be its only purpose.
Thanks,
Eduard
On Mon, Apr 25, 2016 at 3:46 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
--
Thomas Mortagne
On Mon, Apr 25, 2016 at 12:10 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
(that
--
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 On Fri, Apr 22, 2016 at 8:08 PM, Thomas Mortagne
<
thomas.mortagne(a)xwiki.com>
wrote:
> On Fri, Apr 22, 2016 at 5:59 PM, Clemens Klein-Robbenhaar
> <c.robbenhaar(a)espresto.com> wrote:
> >
> >> On Fri, Apr 22, 2016 at 5:34 PM, Thomas Mortagne
> >> <thomas.mortagne(a)xwiki.com> wrote:
> >>> Sounds good.
> >>>
> >>> What about upgrades, do you plan to provide a migrator ?
> >>
> >> (I would love to see my old calendars converted to new style ;))
> >>
> >
> > I have to check out the
>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Nested+Pages+Migrator+…
> > and see how it works / if it can be
adapted to nested pages, etc.
> >
> > I guess this will be a separate application / helper etc in any case,
or
is there
a way to trigger the migration when installing a newer version?
There is an ExtensionUpgradedEvent event that an extension can listen
to be called after it's upgraded.
Cool! Did not know about that. So we can have per-extension migration
scripts, which would kind of superseed the XWiki migration framework work with the XWiki DB version) and we would only
be still using that for
core changes. Right now we use the XWiki DB version even for bundled app
migrations.
I guess we should document that somewhere and make it a best practice (if
not already).
It's OK in Java but impossible to use that in a XAR extension that
might be installed without programming right (since wiki component
require PR).
Thanks,
Eduard
>
> >
> > No deadline for this in my scedule yet, however ....
> >
> >
> >>>
> >>> On Fri, Apr 22, 2016 at 5:31 PM, Clemens Klein-Robbenhaar
> >>> <c.robbenhaar(a)espresto.com> wrote:
> >>>>
> >>>> I see there has been some discussion on the list, as far as I
> understand there is no decision about it in general.
> >>>>
> >>>> However I would like to drop support for pre-nested pages for the
> mocca calendar on the master branch right now.
> >>>>
> >>>> The pre-nested spaces structure is:
> >>>>
> >>>> - Calendars are plain pages
> >>>> - Events are pages that have their calendar as parent page, but
are
> usually placed as siblings in the same space
> >>>> (necessarily w/o nested pages)
> >>>>
> >>>> It is more natural to have calendars as nestable, non-terminal
pages,
> and the corresponding events nested inside
these calendar pages.
> >>>>
> >>>> Bugs that would be easy to solve after dropping support:
> >>>>
> >>>> http://jira.xwiki.org/browse/MOCCACAL-91 "Cannot create two
events
> with the same title in the same calendar
"
> >>>> This has been fixed in 2.5.1 for pre-nested pages, but that fix
> does not work for nested pages.
> >>>> Admittedly it could also be fixed with an if (nested space) do
x
> else y
> >>>> I have to admit that I am reluctant to implement the if-else
fork
> and fully test it (If I do not test both
nested and pre-nested spaces it
> will be broken with high probability)
> >>>> In some places there are already horrible if-else clauses to
> support both colibri and flamingo, which I put there and the experience
> makes me unwilling to try this again with nested spaces.
> >>>>
> >>>> http://jira.xwiki.org/browse/MOCCACAL-93 "Preinstalled
"Other
> Events" Calendar should not be a terminal page"
> >>>> This actually can not be fixed in a pre-nested spaces compatible
> way (I think)
> >>
> >> Another great feature of nested space based calendar: you can watch a
> >> single calendar just by watching its page instead of having to watch
> >> eveything.
> >>
> >>>>
> >>>>
> >>>> Proposal:
> >>>> a) there is already a "stable-2.5" branch.
> >>>> all fixes and improvements for pre-nested spaces will/should go
> on this branch
> >>>> b) master will switch its xwiki platform dependency from 5.4 to
7.4.2
>>>> (not 7.2 for me, because 7.4.2 is what I am willing to test
against ... any takers to test with 7.2 ?)
>>>> c) for now, the old "parent-child" relationship will still be
used
to determine which events belong to which calendar
>>>> so no migration from pre-nested spaces is really necessary - at
least I think so. Of course this should be tested.
>>>> (It would be nice to have such migration, of course. I am not
sure how to write this, however.)
>>>>
>>>>
>>>> Any opinions? Should I send an official [vote] request?
>>>>
>>>> Clemens
>>>> _______________________________________________
>>>> devs mailing list
>>>> devs(a)xwiki.org
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>
>>
>>
>
> mit freundlichen Grüßen
> Clemens Klein-Robbenhaar
>
> --
> Clemens Klein-Robbenhaar
> Software Development
> EsPresto AG
> Breite Str. 30-31
> 10178 Berlin/Germany
> Tel: +49.(0)30.90 226.763
> Fax: +49.(0)30.90 226.760
> robbenhaar(a)espresto.com
> www.espresto.de
>
> HRB 77554 B - Berlin-Charlottenburg
> Vorstand: Maya Biersack, Peter Biersack
> Vorsitzender des Aufsichtsrats: Dipl.-Wirtsch.-Ing. Winfried Weber
> Zertifiziert nach ISO 9001:2008
> _______________________________________________
> 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