Serge Knystautas wrote:
Stephen McConnell wrote: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 agree with 1, but not with 2.
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.
Some clarification: Scenario (1) is getting James into shape so that it is built and distributed based on released jar files from wherever. This is not the case today. James is currently using an unsupported build of cornerstone. James will also needs to upgrade at some point to the new thread jar from excalibur (that includes the fixes concerning pool sizes). This upgrade impacts Phoenix as well because James is currently bound to Phoneix at the level of the code. All of the above is managable stuff that is reflected in the James repository via addition of released jars in lib directories, etc. Key actions that both James and Avalon people need to be concerned about is: * migration to a release for the cornerstone 1.0 components * migration to the updated thread 1.1 * migration to a Phoenix release backed with thrread 1.1 Scenario (2) is about collaborating sufficiently so that release candidates (like the current cornerstone-xxx-1.0 jars and the excalibur-thread-1.1 jar) can be validated. The best approach to this is to establish a Gump based build procedure that is a seperate process that builds James against all of the current Apache repositories. This has been in place for ages and has been failing for ages. Things I'm doing are in part address this disconnect. Some misconceptions: Nobody is suggesting that James move from well defined releases to HEAD depedencies. Gump is an early warning system that will help to keep the James community aware of changes that may impact them across the entire Apache community. I am suggesting that James/Cornerstone dependency get sorted - because the setup in James today with respect to cornerstone is far from satisfactory. Hope that clarifies things. Something else to keep in mind is that I'm moving close to a point where I will be introducing James depedencies into code I'm working on. Having James in Gump (working) provides me with a lot more assurance about things - if something fails - then I've got info about the source (where the source could be James or could be a dependency that James has on some other Apache project).
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).
I disagree with the "slowing adoption" argument. Getting James in sync with avalon releases will accellerate adoption.
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.
Sounds good and I agree in principal. BUT. 1. James needs to dump cornerstone.jar 2. A set of candidate releases of corerstone components have been prepared that incorporate bug fixes raised here. 3. To move from a unreleased and unmaintained corerstone jar to the candidate release means tranition from CM to SM (details on this already supplied). 4. Both Pete and I have done the transition (not a big deal) 5. My testcase is showing problems and I havn't been able to figure out if this is a James, Cornerstone, Excalibur issue. 6. Apparently there are problems in James HEAD that could be contributing to this. 7. I would like to validate Cornerstone and Excalibur candidate released against James BEFORE proposing these packages for Avalon release. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
