22 May
2013
22 May
'13
2:24 p.m.
Another reason is that dynamic languages are a lot less strict than
Java on what's a breakage so many changes don't actually break
anything. We will need to not follow too blindly CLIRR reports on
this. Since we are a bit more relaxed on these issues that we use to
that should do it.
+1 to move public script services out of internal package
IMO the real benefit is that public script services javadoc will be
included in the release javadoc.
On Wed, May 22, 2013 at 8:55 AM, Vincent Massol <vincent(a)massol.net> wrote:
On May 22, 2013, at 8:12 AM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com>
wrote:
--
Thomas Mortagne
On Tue, May 21, 2013 at 1:10 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I don't think it changes anything. Right now SS can be injected in Java code already
since they're components. The fact that they're in the internal package
doesn't change much.
If we really want to check that they are not used by Java code we could write a check but
I don't feel it happens enough to be necessary to spend the time to write that check.
I'd say we don't FTM and if the problems happens then we can write a check.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi devs,
We need to solve http://jira.xwiki.org/browse/XWIKI-9157
I'm proposing to simply move all ScriptService implementations out of the internal
package and make that a rule.
These classes are used by introspection and as such as not used as components and thus
they should not be in the internal package.
Here's my +1 and I'm proposing to handle the move.
I can't think of anything that would break except some users who would have had an
import in a groovy script on some internal Script Service but that's ok IMO.
One of the main reasons to keep the ScriptService implementations
internal was to discourage their usage in Java code (as they can be
injected like any other component). What do we do about this?