Hi, I will send in my vote this weekend after reading more about the Avalon architecture.
Mike, do you have any guesstimates on how long the conversion would take? Weeks? Months? We really need to create at least one branch. Always working off the mainline is one of the reasons we cannot get a new release out. People keep checking in brand new code/functionality. Thanks, Kevin --- Berin Loritsch <[EMAIL PROTECTED]> wrote: > Stover, Michael wrote: > > Hi all, > > Berin has convinced me that using the > Avalon-Excalibur framework in > > JMeter would be helpful. I'd like to know if > everyone is agreeable to > > letting me rework JMeter's structure to do this. > > > > to be specific, it will require changing the > interfaces (such as > > JMeterComponentModel and ModelSupported, Saveable, > etc). The way new > > components would be written would change (the idea > is to make is easier and > > more consistent). > > > > I think the benefits of this would be: > > 1. Simpler and more consistent process to create > new components > > 2. Remove dependence on Swing in non-gui classes > > 3. Better design resulting in easier to manage and > less buggy code > > 4. Possibly more flexibility in the types of > components JMeter handles > > (right now there's a rigid and somewhat arbitrary > categorization of > > components as "timers", "listeners", "config > elements", "logic controllers", > > and "generative controllers". "Assertions" and > "Modifiers" were new > > elements that have been tacked on. Using Avalon, > the organization of > > existing and new elements would be much more > flexible. > > All of those are good. > > Other examples of Avalon based projects include: > Apache Cocoon > Apache JAMES > FOP > > > > > Only fair to list what I see are the > disadvantages: > > 1. Lot's of work that will delay many new features > everyone wants > > (cut/copy/paste, better reports/visualizers, etc). > > 2. Work that may interfere with what you are > working on currently > > These disadvantages can be taken care of in a way > that we are modular > about what we are doing at any one time. > > > > > And, the risks: > > 1. May introduce complexity for relatively little > gain. Berin probably > > doesn't see this as a risk, cause he is > comfortable with Avalon. It looks > > pretty good to me, but I see the potential that > the new abstractions may > > confuse things, and not produce as much benefit as > I think. Obviously, I've > > decided this risk is small, but others may not > think so. > > It actually reduces complexity. Currently, the > JMeter code is fairly > convoluted and difficult to follow. By adhering to > the principles of > Component Oriented Programming, the system can grow > in a healthy manner > that is flexible and easy to follow. > > We also gain the ability to use the test harnesses > to provide sanity > checks before release. > > > > > Perhaps a branch could be made for this work. I'd > rather avoid that though, > > if possible. > > > > Any thoughts? > > > I am +1 (of course) > > As to the branch question, you will have to answer > that based on how you > feel that would manage the risk of the conversion. > > If you have any questions I will be happy to answer > them. > > > -- > > "They that give up essential liberty to obtain a > little temporary safety > deserve neither liberty nor safety." > - Benjamin Franklin > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
