Leo Simons wrote:
I've reordered some bits a little. Attempt at SOC.
Tech stuff ----------
This is the underlying problem to lack of specification, which I have been jumping up and down over before, but haven't had time to really dig into.
IMNSHO it is a good idea to dig into things before making big changes.
If I write a Servlet against ver 2.3 of the spec, it won't run in Servelet 2.2 containers. Simple as that, and this is no different.
My point is that it /is/ different (not that I always approve of the way the JCP manages changes to their specs). See my other reply. The servlet spec didn't introduce reflection-based magic into what used to be a purely interface-based contract.
Not entirely sure what you are trying to communicate here. I think you are trying to hint that I say that the Servlet spec evolution is very different from the Avalon spec evolution, and nothing much more, but I could be wrong.
To answer that; My interpretation of your initial assertions were that any change of the specification must keep all previous containers compatible, which is what I tried to highlight with the Servlet spec.
A 2.2 container may or may not be able to execute Servlets that has been written by someone looking at the 2.3 spec.
If your initial assertion is claiming more, then that is a different issue.
Not-so-techy stuff ------------------
Closer to home is what is happening in Excalibur TLP, many things are axed breaking compatibility for 'satellite' projects
Deprecation is not the same as breaking compatibility. In fact, since there's no new release of the things being deprecated (I really don't like "axed" as a term), compatibility can't be broken!
1. Why is 'disappearing altogether' better than 'changes in recommended usage' ??
Deprecating avalon-framework alltogether would be different from changing it. I have no problems with deprecating avalon-framework.
I haven't seen Excalibur Chair vetoed any of those changes.
Since I am trying to keep personality out of the debate :o) I said 'Excalibur Chair', when I should have said YOU!! :o)
I haven't studied the details of all the re-work being done in Excalibur, but I have a distinct feeling that my (as if I had any) apps written with these components will not work in the 'yet-to-be-released' next Fortress. I am basing this on;
1. Most parts that are being 'discontinued' are replaced with external equivalents.
2. I assume that will indicate that an upcoming distro will include these parts, and not the Excalibur ancestors.
3. I further assume that the external parts are not in the previous namespace, in which case, they are not source/binary compatible with my (figuratively) applications using these parts.
How can it possibly be interpreted in any other way??
(Long discussion about what is not really a concern here.)
The point; Do what you teach, before people will listen. (This sounds a bit harsh, and not intended as any kind of personal criticism, but something I was taught as a kid...)
which the 'pico camp' is arguing so strongly against funny enough
Besides there being no 'pico camp' (just pragmatic people who write lots of tests), I haven't seen the pico project argue strongly against anything. I do agree that some of the guys who hang around there can be pretty funny ;)
I see you are one of those with the funny humor... (That I don't have :o( )
Are you saying what I think you are you saying? "We are not going to discuss these big changes with you (or other people that happen to disagree) that impact your (their) work because <nasty stuff> will happen?"Regarding the 'discuss the changes' more thoroughly; We all know where that will end up.
Are you serious?
I am serious that any flamefests over technical direction of Avalon 5 Single Unified Platform, and nit-picking over class and method names, stalemates over irrelevant details, and so on (as if you never seen it here before) will NOT be entertained.
Like it or not, ASF are useless to define standards, because their are too many 'egos' (I am one, you are another, just to make that clear) and 'shed color opinion makers', and very few painters.
End of the day, the color doesn't matter much. Leave it up to the people that does the work, you may not like it, but it is not bad enough for you to repaint it yourself, so just move on to next topic.
Can I live with the fact that it is hard (almost impossible) to write components according to the non-existent 4.1/4.2 Avalon spec, that will run in ALL Avalon-labeled containers??
Yes, no problem.
Can I live with the fact that there will be changes and additions to the specifications, that eventually leads to most components written against such spec will benefit tremendously in terms of project development, but they won't work in Fortress, ECM and others? (Unless these decides to implement them as well.)
Yes, I have no problem with that at all.
Can I live with introducing a Specification Rule that should be in the AF contract, but is not, which will render all containers (incl. Merlin) non-compliant? Yes, I have no problem with that either.
We live in a world of 'evolve or die'. Someone else is around the corner, about to take away all your glory and your efforts will end up in the history books and fossil records, at best. Avalon 5 wants to become the thing around the corner.
Also, the AF4 is so hollow when it comes to 'specification' that you need a PhD in forensic science to be able to work out what is part of the specification and what is implementation variations in implemented containers, OR worst case (like Selectors) BOTH.
I look at your Example (thread with Steve), and I can't see anything with it that violates the AF4.2 or later AF4.x (if any). It won't play nice with Merlin (or Fortress for that matter) as the meta info is missing. So, I honestly have the impression that you are jumping up and down over a non-issue (the AF4.2 release, which is almost an intact codebase).
I like you Leo a lot, as Stephen does, but you are a bit reactionary and assumes (read into a statement) a lot that isn't there. Diff the codebase and present something that is questionable. Present a valid testcase that works for AF4.1 but not in 4.2.
Be a painter, not the board member deciding the color.
Cheers Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
