Noel J. Bergman wrote:
I now have two james builds locally on my machine:[talking as an engineer] The best solution is to make a branch, and give
temporary karma to Stephen to be able to work on that branch.
+1 Since we are working on James v3, and not impacting the stable v2 branch, I'm fine with it. Plus, this is part of what is being done to produce the Avalon Coordinated Release build.
1. James based on Peter's derivative of 2.1, CM/SM
migration and Cornerstone candidates in place.
This is working fine. Some problems were occuring
in the test case but we finally narrowed this down
to a bug in the test case (the test delete's the user
before the spool completes its work, resulting in
email in the spool that contain invalid reciipient
addresses).
2. James based on HEAD + CM/SM migration + updates for
Cornerstone candidates. This version is doing the
500 error on "" commands and getting itself into a
loop. However, it's fully synced with the HEAD and
can be committed.
I suggest we go ahead and ties build (2) into head and sort of the loop/500 problem from there.
Avalon peeps have been busy getting a lot of little things up-to-date on the Excalibur side - thing like version information, manifest and so on. Also Gump status across the Excalibur suite is looking much better. The cornerstone candidates need to be updated to create dist targets with their doc etc. and respective gump entries. That will help get James Gump running. The same story applied to Cocoon which is dependent on some of the same Cornerstone component as James (but currently tied to the entire Cornerstone project). There have been a couple of updates to Excalibur that need to propergeted to applications like Phoenix and Cocoon - in particular excalibur-thread-1.1, excalibur-pool-1.2, and maybe a excalibur i18n-1.1. There are some recent framework related wrapper classes that have been introduced but can/could/should be moved out (more Avalon dev discussion needed). Aside from that - there is formal release process required for excalibur-configuration, excalibur-sourceresolver, and possible excalibur-xmlutil.
Any idea how far off the ACR is at this point?
There is also the question of migration of excalibur-xxx packages to commons-xxxx. This has been taken care of for the pool package (commons-collection). There may be a coupe of other packages that require transition. Also, excalibur-cli (used in Phoenix and a couple of Excalibur projects) can/should/could be replaced by commons-cli.
i.e. Things are already looking comfortable - and within a few weeks we should be able to freeze the release targets and validate things across containers, applications and external projects followed by formal vote/release/publication.
I'm sure that you'll need to check with Cocoon, Jesktop, and other clients, as well as James.Yep - its in progress. Some of the updated in Excalibur are used extensively in Cocoon and some of guys on working on the Avalon/Cocoon front in much the same we as I'm trying to get James/Avalon in sync.
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]>
