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 <[email protected]> wrote: > > On May 22, 2013, at 8:12 AM, Marius Dumitru Florea > <[email protected]> wrote: > >> On Tue, May 21, 2013 at 1:10 PM, Vincent Massol <[email protected]> wrote: >>> 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? > > 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
