Leo Simons wrote:
Proposal? What proposal? Why is everything always called proposal? ------------------------------------------------------------------
I could give you a really synical answer to that but I won't! In practice I think flagging something as a proposal does hint at a precursor to a decision.
ok. Read it, digested most e-mails on the subject. Didn't feel like thoroughly reading everything. You guys produced approximately 100 A4 pages of mails on this I think.
Seems like avalon-meta is ready for a first release and containers can be updated to use it. I think there's something in place that works. For me it is way overkill but its not in the way either.
So, what is the actual proposal?
Rename avalon-meta to AMTAGS? Why? Better to just loose the AMTAGS name if you ask me. Avalon-meta is clearer.
Migrate avalon-meta from the sandbox? Do a few alpha releases first, imo.
+1
IMHO this is the only strategy that makes sence.
Add support for tags, by using avalon-meta, to all containers? Sure. Enthusiastic +0.
On Part2 and Part3 vs just one Part ----------------------------------- No, I need none of
@avalon.stage @avalon.extensions @avalon.logger @avalon.context @avalon.entry
but I don't see a problem with them either. Go ahead and just do all of that. We can always change it later.
I do like configuration validation. It'd be real nice to have fortress do it :D
Some actual comments on tags ----------------------------
@avalon.component
The whole versioning scheme should be explained. I think Steve previously answered most of the questions I posed but that didn't make it into the docs yet apparently.
I can take care of that either before or after a release. Personally I would prefer to do it after with a little more time to document it properly, but I can do it now if its view as a critical thing. Just for reference, while you were away I updated the Version class in framework to support the notion of an undefined version (represented as -1). By default the versions associated with any dependency (service runtime dependencies and stage dependencies) defaults to -1 (i.e. any version, i.e. ignore version). This simply means that not declaring versions will not interfere with anything.
@avalon.attribute
I still think it is silly to have an attribute named attribute. Mad.
Lets deal with this post 1.0. The attribute management still needs to be done and with that in place the need for @avalon.attribute disappears.
@avalon.service
comment on versioning above applies.
Noted.
@avalon.stage @avalon.extensions
so no @lifecycle then?
We have a choice of either:
(a) completely addressing the entities at the current level of abstraction (b) changing the abstraction of the entire model
Or to put it more simply - the current level of abstraction deals with the expression of constraints that a component implies towards a container. If the constraint set is incomplete the solution is dysfunctional. If we consider lifecycle outside of the current abstraction then we have to rebuild the Avalon abstraction to encompass custom abstraction inclusion. This is a non-trivial problem that should be investigated and experimented with based on real requirements.
@avalon.logger
there's an @avalon.configuration up next that is new (to me), and you didn't list it either.
Sorry about that - but it is listed here: http://avalon.apache.org/sandbox/avalon-meta/tools/tags/index.html
I guess this can be a relaxng reference and is similar to phoenix config validation:
That's the objective.
Peter Royal wrote a long time ago (thanks google): > Phoenix will look for a schema-type element in the blockinfo document, > and if it is found, will attempt to load <block>-schema.xml as the > schema. If you are using the xdoclet xinfo generation, add > @phoenix:configuration-schema type="<type>" in the javadocs of the > configure() method.)
is this avalon-meta thing just for relaxng schemas as well? Is there a need to support different schemas? Is there actual code to support this?
There is code in the Phoenix repository that handles this. I was thinking about what we could do at a tool level to validate configurations ahead of deployment (and I'm still thinking - no solid opinion yet).
@avalon.context
as long as we're clear on the notion that actually extending the context interface is bad practice :D
Calling it a bad practice feels a little over the top to me. In proactive it’s a balance - on one hand the component developer is restricting their deployment options (because not all containers provide implementation support), on the other hand, users like using domain based context objects. The decision that a developer makes in this regard is neither good nor bad. It’s simply a decision. But I know what your saying - sort of agree - but wanted to state the concern more completely.
@avalon.entry @avalon.dependency
> Remaining Issues > ----------------
leave those for v1.1 if you ask me :D
I agree.
Cheers, Steve.
--
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]
