Hi Paul,
On 18 Jan 2016 at 11:51:40, Paul Libbrecht (paul@hoplahup.net(mailto:paul@hoplahup.net))
wrote:
Vincent,
is there not a need to version the legacy?
Legacy jars are versioned btw (same vesion as platform). What do you have in mind?
I know of no installation that does not have the
legacy jars
All our functional tests do not have legacy jars and this ensures that all the code we
produce don’t use legacified APIs.
and I
wonder if this could not be better controlled so that installers can
actively get rid of the legacy.
Our current strategy has been to keep legacy forever, see:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar…
Our idea was to start not bundling legacy jars by default but we need the EM to support
legacy jars first as otherwise users will see breakages when they install extensions
requiring legacy APIs.
Do you have a different idea?
Thanks
-Vincent
paul
vincent(a)massol.net
18 January 2016 at 11:03
Hi devs,
After a lot of thinking and experimentation (see the thread’s
details), I have found that this first proposal is not a good idea.
I’m thus proposing to replace it with the following best practice:
* Let our script services generate exceptions
* If the velocity scripts with to handle the exceptions, then they
should use the #try() directive. If they don’t want to, they don’t
have to do anything since the MacroTransformation or the template
(contentvars.vm for example) will catch it and display it to the user.
More precisely I’m proposing that:
* Existing Script APIs in Java should not be modified as that would
break backward compatibility. New signatures can be added and old one
deprecated and moved to the legacy modules. After new signatures have
been introduced, existing velocity scripts can be updated to use the
new signatures and to use the #try directive if needed.
* New Script APIs must use the new best practices (if agreed :)), i.e.
throw Exceptions, and new velocity scripts must use the #try()
directive if they need to handle exceptions.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
vincent(a)massol.net
14 January 2016 at 17:51
Hi devs,
Right now our strategy is for script services and script APIs in
general to catch exceptions, store them and offer a getLastError()
method to get them (see
http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPra…)
However it would be much nicer to:
* Let our script services generate exceptions
* Offer a velocity script service to get the last exception raised by
a java call from velocity
* Implement this uberspector to catch the exceptions and to set them
in the execution context
That should be quite easy to implement IMO.
WDYT?
Thanks
-Vincent
PS: This is
http://jira.xwiki.org/browse/XWIKI-2374
_______________________________________________
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