The first step in writing the component is determining how it is going to be used. There will be a number of times where you have a powerful component that can be used in many different contexts. Those contexts may include executing the component from the command line (separate from Avalon), using it as a part of a sub system, or using it as an integral part of Avalon.
All components are an integral part of Avalon, so there is really nothing to be done beyond specifying its interface (role). It is important to identify and document its social contract with the rest of the system. What I mean by social contract is the order of dependencies, what it needs to function, and what it supplies to the rest of the system.
A sub system can either be part of Avalon, or live in a separate context. A perfect example would be a component that can function within a Servlet or Enterprise Application. Neither of those contexts are native to Avalon (though they can easily be built on top of Avalon).
It is important to do even more careful planning than in the first scenario. The reason is that you want the interface to be as generic as possible and still accurately represent its role.
Because the contexts may not be an integral part of Avalon, you must take care to use the component in the same manner as Avalon would. That means that you follow the order of concerns that Avalon has specified for those concerns.
When you are designing a component to be run from the command line (or directly by the operating system), try to separate the main function from the component itself. This is imperative in order to maintain the passive API of Avalon. By designing your component in the manner stated in the previous section, you have effectively minimized what the main function has to do.
Follow the practice of having an object dedicated to the main function that includes the parsing of the command line parameters and initialization of the component. When the component is used the exact same way in every context (including the command line), you minimize the number of locations to look while debugging.
A common mistake is to combine the main function in the implementation of the component. This requires violating the contracts and principles that Avalon is built upon. This violation of the pattern of "Inversion of Control" is aptly dubbed "Subversion of Control" (thanks to Steven Coffman for the name of the anti-pattern).