Stephen McConnell wrote:
I agree with 1, but not with 2.There are two scenarios I think you should be considering:1. a James releasse scenario - this is where you referencing relased jars 2. a James build that is based on the current CVS of Avalon based on Gump
I don't think it does James any good to treat the Avalon jar dependencies any different than we would other libraries. I also don't think it does Avalon any good in the long term.
I know it's not ideal, but for me the big API change that happened in the Avalon project (Component -> Service I think it was) is not that big of a deal. What made it a big deal is that there was not much of a clear release beforehand, I don't think any release (yet) after the fact, and I haven't heard of a changelog or HOWTO to help users make this change.
Codebases change all the time, and I have to believe the Avalon committers did what they felt was a right by moving to a different naming/design pattern. But with software engineering, you need software development practices to support it.
As an example with another open source project, we use Netsaint for monitoring. This was basically disolved, and the authors went and refactored the codebase into Nagios. I don't mind that Netsaint isn't supported or that my large conf file needs to be completely rewritten... because there is explanation of what happened, clear releases so I can stay with Netsaint until we have the time to migrate, and I've heard rumor there is a conversion tool out there to help you migrate your conf file. These practices allow me to handle the change, and this is better than having Nagios people who are very willing to help because in the end, I know my code/system best and need to understand how to apply it.
These software development practices allow the software engineering to happen with less restrictions. For the Avalon community, having James build against Avalon and have Avalon committers help James with that is a misdirection of resources (IMHO). You will get James working on it, but at the expense of other activities that can slow adoption of the codebase (which ultimately James needs to see happen as well).
So, I think Avalon should be treated just like other dependencies... people can propose updates, the community reviews it, and then if approved, the update happens.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
