Yeah - that's probably a good idea. Now that it's on a branch it wont stop normal bug fixes and development on the trunk.
The refactor should not affect most users. It's deep down in the internal workings of JSPWiki. It might affect those that have made major customisations, or those who have written custom plugins/features. But otherwise it will just be a normal upgrade. The main advantage will be to make it more modular, and easier to write TestCases and easier to internally organise/edit/add modules/components. Cheers, David V On Tue, Jun 23, 2015 at 10:06 PM, David (spindift) <demer...@spindrift.com> wrote: > If you're planning on making a large-ish refactor, it would be nice to > have an official release prior to introducing the changes. That would > consolidate the updates-to-date into a new official baseline. > > Just a thought... > DaveE > > > On 6/23/2015 7:47 AM, David Vittor wrote: > >> Hi All, >> >> I've decided to remove this from trunk, as I will be unavailable to >> support this for a few weeks. >> >> I've reverted the trunk and checked in the changes to a Branch: >> https://svn.apache.org/repos/asf/jspwiki/branches/JSPWIKI_2_10_PICO_BRANCH >> >> I've also attached here a pico.patch in case someone wants to test this >> against their version of trunk source. Apply the patch on the current >> version 2.10.2-svn-17. >> >> Let me know your thoughts if you do get to test this, and I'll see if I >> can merge this into the trunk, when I have more time. >> >> Kind regards, >> David V >> >> >> On Tue, Jun 23, 2015 at 9:09 PM, David Vittor <dvit...@gmail.com <mailto: >> dvit...@gmail.com>> wrote: >> >> Hi Devs, >> >> Following close on the heels of the Haddock template rewrite, I've >> released 2.10.2-svn-18 - a small rewrite of the core WikiEngine. >> >> I've been doing a some research into Dependency Injection, I've >> decided that for JSPWiki, I think the best framework would be >> PicoContainer. >> http://picocontainer.com/ >> >> This change will take a long time to complete, but I've started by >> adding it to the pom.xml, changing the ClassUtil class to create >> and list all the "components" (InternalModule), and changing these >> modules (SearchManager, AdminBeanManager, WorkflowManager, >> DefaultFitlerManager, etc) to have empty constructors, and a >> method called initialize( WikiEngine, Properties ). >> >> Just the above change took ages to get right, but now all test >> cases pass, and I've played with it in my dev environment and >> seems like everything works. >> >> I hope now that the core is in place, we can slowly start making >> changes to actually use the PicoContainer functionality for >> dynamic component injection. >> >> I have made a trade off however. Currently the file >> "ini/classmappings.xml" is no longer valid, and the core classes >> are hard coded inside "ClassUtil". >> >> Let me know if anyone has any thoughts on this. >> >> Kind regards, >> David V >> >> >> >
