Berin Loritsch wrote:
Stephen McConnell wrote:
Berin Loritsch wrote:
Stephen McConnell wrote:
Extensions became intrinsic to the component deployment model when we voted for the release of the excalibur-extension package (a vote that received your +1). At that point we said to everyone out there that there is a notion of lifecycle stage extensions in Avalon. We documented in that release the support for that abstraction in both Merlin and Fortress. There are simply no issues to solve - this is simply a matter of getting back to a process of collaboration.
I don't buy that reasoning. Lifecycle extensions (as released) are a set of interfaces. Those interfaces work. Currently Fortress and Merlin have two different ways of addressing how to work with them. I don't think you have been listening to the points I have been raising either.
Could you please take a moment to detail any problems you see concerning stage management. I have (on at least two occuations) offered to assist you on this subjet and remain willing to help you out on this. Perhaps we can nail down you technical concerns once and for all.
Here they are (mostly related to growing the API):
* First, when growing an API we need to get everyone on board so that they
understand what that API is doing.
* confirming that this process is premature
* Second, we need a way for users to be able to play with the new functionality
without being lulled into thinking everyone is on board with it. While the
Avalon namespace does imply that, IMO is should only be used for pure Avalon
components.
* confirming that we should release outside of the core Avalon namespace
* confirming that more time is needed for users to experiment and provide feedback
* Third, I believe that we should embrace a multi-namespace world (we will have
to for management extensions). This could lay the foundation for container
extensions which in turn would encourage users to embrace tags not specified
in the Avalon namespace. Esp. when it doesn't matter what container they
use, they can still keep the same functionality.
We agree on this - but I suspect we disagree on the details. I mentioned a couple of time before that I think this subject should be addressed based on experience in dealing with real problems. The subject will arise following a release of Merlin as we move forward with a comprehensive JMX solution. Throughout that process I am confident that we will gain a lot more insight into what belongs where.
* Fourth, in my mind the stage/extension stuff is a risk due to the general lack
of knowledge with it. While I do want to understand it, that takes time, and
I would rather have a release of Meta-info now so we can start integrating the
libraries.
* confirming that this is largely a question of insufficient understanding
* confirming that the current vote can be held up as representing a representative opinion
* confirming that this process is premature
* Lastly, we need to manage user expectation. I have a project that will be
using the lifecycle extensions, so it is of great interest to me. It will
also help me to understand what I do and don't like about the way it is now.
Until such a time, I really don't feel comfortable signing off on them being
in the Avalon namespace.
* confirming that your vote is really about your level of understanding * confirming that this process is premature
Berin:
There are no technical issues in your email. Instead what you have said is that you are:
(a) opposed to introducing something into the Avalon namespace that you don't understand
(b) feel that a broader base of developer knowledge is needed
(c) that more user experience is needed
All of these points I can understand. However, your vote does not say this - in fact it calls up people to make a decision on a subject that is directly linked to a question concerning extension management that you yourself do not feel competent to address at this time.
I think that some time and experience with a released Merlin will go a long way towards addressing all three of the points you have raised. It would ensure a broader knowledge base, greater experience, and as a consequence, future actions can be taken with full knowledge and responsibility as to the actions we propose, the votes that we take, and the implications of those decisions.
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
