Stephen,
<chuckle/>
I was thinking about you when I wrote my reply to Pete.
Yup, I'm compulsed to mediate...
Yes - I think the framework is valid case for this - it is sufficient small that we can be explicit about which files are client side and which represent implementation and include this in the build file during jar generation (i.e. we don't need to change any implemetation package names). I also think this would be a good move in that it gives us a little more flexibility to evolve the implementation content.Agree if thats as far as you and others travel. The -impl suffix may be a practical summary of "Reference Implementation". That is as long as the Reference Implementation term is stamped prominently against thedescription of the download. My angle on this is that newbies get very confused as is. I am for increases is precision. when it comes to naming.
Other suggestions for jar filenames ...
<product>-api.jar -- the interfaces
<product>-impl.jar -- the implemetation
<product>.jar -- the combination
On defaults - I don't think there should defaults unless there is a clear case for the default. In the example of the container/lifecycle case we have the appropriate defaults already in place to support convinient development for the client. However, defaults related to implemetations at the container levels is a lot trickier. With continued work on the Foress meta handling, its much easier to see a default implemetation emerging as a result of convergence between Fortress and Merlin. So what I'm saying is that some cases make sence and other's don't.Meta: All our containers use different component lacing schemes and there is nothing wrong with that.
The term 'default' I object to unless it is used in context "Avalon-Framework Reference Implementation Default Configuration" (an example). If just expressed as "Default Configuration" then it will add to confusion. It gives it a level of authority it does not have if used with imprecise naming. When used with Ref-Impl, people will know it is not going to be used everywhere. It is almost an example of use. Maybe the best thing would be for Tweety to be part of the A-F refimpl jar.
Regards,
- Paul
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
