Hello, Thanks for your proposal and analysis. If you're willing to contribute there are already a lot of existing enhancements/bugs to fix that would give you a better idea of why JMeter code is like that , and how it is possible to change it in a realistic way having in mind that there are a lot of existing plugins and that backward compatibility is important within the project.
It is good to have Theorical ideas of clean design, but I think as a student you'll learn a lot from starting with small fixes, then medium fixes, then architectural breaking changes. I share Emilian opinion of "not refactoring just for synthetic reasons", and as usual I think that proposal shoud be if possible based on concrete code (POC or full code). Regards On Sun, Jul 23, 2017 at 4:50 PM, João Paulo Lemes Machado < [email protected]> wrote: > Hello everyone. > > My name is João Paulo, I am a graduate student the Federal University of > Uberlandia, Brazil. > > I was analyzing the modularization of some classes of JMeter, and I > identified some opportunities for cohesion improvement in the following > classes: > > SampleSaveConfiguration > JMeterUtils > SampleResult > > > Could you please take a look and tell me if it's viable? > > Maybe some of these classes could benefit from some kind of refactoring > that we can discuss. > > I created the following issues for each class: > https://bz.apache.org/bugzilla/show_bug.cgi?id=61309 > https://bz.apache.org/bugzilla/show_bug.cgi?id=61308 > https://bz.apache.org/bugzilla/show_bug.cgi?id=61306 > -- Cordialement. Philippe Mouawad.
