On 08/09/2011 04:54 AM, Vincent Massol wrote: > > On Aug 9, 2011, at 10:39 AM, Caleb James DeLisle wrote: > >> +1 >> >> How should we signify code which depends on the oldcore and is interrelated >> so that it can be separated from code which does not? > > Well our rules is that all new modules must not have direct dependencies on > the old core and instead go through the bridge. > Whenever we couldn't do this we've put the classes in the old core. > > I know there are some exceptions: > - some people have not followed this rule
I guess I have made a mistake then in store and not put things where they should be. > - in some cases putting stuff in old core wasn't good enough > >> I have so far been using com.xpn.xwiki mainly to indicate "this code will be >> gone when oldcore goes". > > The problem is using com.xpn is plain wrong in general and we need to move > away from it (the xpn company doesn't exist anymore + this is commercial > package where we're doing non commercial open source dev ). > >> Perhaps adding a -legacy to the module name? > > We already have a -legacy module for deprecated stuff that shouldn't be used. > It's usage is different so I wouldn't use -legacy for that. > > I'd do as we currently do: > - go through the model bridge Just because you put up a bridge doesn't eliminate the dependency on the old core. Looking at the existing bridges, particularly DocumentAccessBridge, I see no way that the new core is ever going to be able to implement all of those apis so anything that depends on the bridge depends on the old core. Not to criticize the idea of a bridge in general, I just think that we still need some separation of the "consumer" code that will need to be modified when the old core is dropped, and the "producer" code which will need no modification at all. I have done that in -store. store-api, store-transaction, store-filesystem, and store-serialization have no dependency on the old core while store-filesystem-attachments does. I suppose it would work just to separate out the code into different modules which either do or don't depend on core/bridge so that core is as well contained as possible. Caleb > - put classes in old core when there's no other way > - (longer run) refactor more foundational code by rewriting it as separate > modules and thus allowing new code to use it without depending on the old core > > Our main issue right now is that almost nobody in the devs are working on > improving our foundations (i.e. introducing/working on new architecture > modules). Here are some modules for which work has started but not finished: > - xwiki-action > - xwiki-url > - xwiki-skin > - xwiki-model > - xwiki-localization > - xwiki-users > - xwiki-rights > - etc. > > Thanks > -Vincent > >> Caleb >> >> On 08/09/2011 04:20 AM, Vincent Massol wrote: >>> Hi devs, >>> >>> I've updated the doc on >>> http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HPackagenames >>> >>> From: >>> * All code that is **not** moved to the new XWiki Architecture based on >>> components should use ##com.xpn.xwiki##. New architecture code should use >>> ##org.xwiki##. >>> >>> To: >>> * All code that is not located in the oldcore module should use >>> ##org.xwiki##. >>> >>> Hope it's ok with you. >>> >>> Thanks >>> -Vincent > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
