Hi Glen! Thanks for the feedback. I fully understand your concern. I would not attempt to change any component/structure of the source code but rather provide a high-level design view of JSPWiki to fellow developers. This high-level design view will solely depend on the structure of the source code. For example, components/classes that behave similarity (method call, shared variable, share data, etc.) will be clustered into the same package diagram. Ultimately, I hope the resulting high-level design view can improve the modularity of future release of JSPWiki
On Tue, May 14, 2013 at 8:51 PM, Glen Mazza <glen.ma...@gmail.com> wrote: > Hi Chun. Could be a good idea, much of our code may be rather old and > could use a reexamination. I work still at a macro level with JSPWiki so > can't answer yet which modules could use improvement--perhaps others can > give you a suggestion. > > We're already modularizing as part of Maven, but the modularization you > mention is of a much more granular (class-level) manner, so I don't think > your work would effect that. Main concern I have is that many university > types get bored after a few weeks and end up switching projects so I > wouldn't want any massive changes to JSPWiki that are dependent on your > presence and would leave JSPWiki in a heavily unfinished state if you were > to leave it. In other words, I'll let you paint a house if you paint > room-by-room, so if you leave there can only be one unfinished room to deal > with; *not* by painting 10% of every room before finishing any, requiring > *every* room to be repainted if you leave. > > Another concern is that sometimes the class design necessary for beautiful > UML diagrams and that for easy understanding and maintenance are not the > same. > > Glen > > > On 05/14/2013 04:13 AM, Chun Yong Chong wrote: > >> Dear devs, >> >> I understand that jspwiki is in incubator stage and requires contributors >> to improve the project. I am currently developing an algorithm to reverse >> engineer java source codes into clusters of cohesive classes to give a >> better view of the software design. The output will be represented in UML >> class and package diagram. The output will assist developers when >> modifying >> or adding new modules into the system. Developers can easily identify >> correlated software components when modifying a particular module. >> Thus, I hope to receive some ideas from fellow developers as in which >> module of the software requires re-modularization. Finally, I hope that >> interested developers can assist me in verifying the quality of the output >> after re-modularization. >> >> Thanks and regards, >> Chong >> >> >
