Hi devs, Here is the general idea: I would like to start doing important cleanup to oldcore project by moving aspect to xwiki-legacy and deprecated stuff hard to move right now. Here are the pros: * we will be able to move a lots of deprecated classes like the old event system and some others to xwiki-legacy. It's very hard now because of methods using theses APIs in XWiki class * oldcore will be quicker to build (no aspectj build anymore) * that way we make sure we don't use any deprecated APIs in platform Along with it I would also like to start separating xwiki-legacy in sub modules. In details it means that there will be two xwiki-oldcore jars, the "normal" one and the one including aspects and legacy classes. Projects will depends on the first one and the second one will actually be packaged with XE/XEM. And It will basically be the same for any other project with aspect based retro-compatibility. You can have a look at the current state which is pretty much ready to merge (need to update some code that is still using deprecated API) in https://github.com/xwiki/xwiki-platform/tree/feature-legacyprojects. Right now only oldcore have a conflicting jar package, other legacy modules are like xwiki-legacy used to be: they just contains some deprecated classes and bridges but they are not repackaging the non legacy jar because it's not really needed (no aspects). There is lots of more things to move but I would like to validate the idea and we will move stuff later. WDYT ? here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi devs, Here is the general idea: I would like to start doing important cleanup to oldcore project by moving aspect to xwiki-legacy and deprecated stuff hard to move right now. Here are the pros: * we will be able to move a lots of deprecated classes like the old event system and some others to xwiki-legacy. It's very hard now because of methods using theses APIs in XWiki class * oldcore will be quicker to build (no aspectj build anymore) * that way we make sure we don't use any deprecated APIs in platform Along with it I would also like to start separating xwiki-legacy in sub modules. In details it means that there will be two xwiki-oldcore jars, the "normal" one and the one including aspects and legacy classes. Projects will depends on the first one and the second one will actually be packaged with XE/XEM. And It will basically be the same for any other project with aspect based retro-compatibility. You can have a look at the current state which is pretty much ready to merge (need to update some code that is still using deprecated API) in https://github.com/xwiki/xwiki-platform/tree/feature-legacyprojects. Right now only oldcore have a conflicting jar package, other legacy modules are like xwiki-legacy used to be: they just contains some deprecated classes and bridges but they are not repackaging the non legacy jar because it's not really needed (no aspects). There is lots of more things to move but I would like to validate the idea and we will move stuff later. WDYT ? here is my +1 -- Thomas Mortagne