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]>
