Serge Knystautas wrote:
----- Original Message -----
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
I don't know if we need a vote, but ...
Do we agree that it is a good idea to create a temporary branch for
purposes
of resolving our Avalon conflicts? We can make the changes to HEAD
directly, but that would temporarily disable your ability to build
runnable
James (other than from branch_2_1_fcs) until we finished.
A couple of thoughts...
1. I'd like to hear more of the case for upgrading our Avalon components.
We have a working version, and I haven't seen a case made for what
features/fixes we're after that justifies the upgrade work, just that it
doesn't compile against what's in Avalon's CVS. I wouldn't really
discourage anyone from doing the upgrade mind you, it's just that we've got
an underlying library that changes API and features, sometimes without
changing version numbers, so without listing the benefits, it's the kind of
upgrade I generally think a lot about before doing. Even the rarely
released and stable package of JavaMail/JAF went through a qualification of
what bugs/improvements we wanted with the upgrade, as with DnsJava.
1. James integrity
* building against a cornerstone base that is actually supported
* reducing dependency of Avalon framework by getting rid of the
component interface dependecies (once you switch over to
ServiceManager you are not longer limited to Avalon Components)
2. James flexibility and independence
* introduce a choice in the James deployment strategy
(including embedded James deployment scenarios)
* elimination of container depedencies (instead of building against
Phoneix jars you would be building against relased jars from Avalon)
* leverage opporuntities arrising from Avalon work on a common container
architecture
3. Help Avalon rationalize
* James building against Cornerstone and Excalibur components directly
* Immidiate automated feedback from James to Avalon when something
breaks (ourside, yourside, whatever)
Cheers, Steve.
2. I don't think whoever is making these changes should commit changes until
you have a runnable James (or at least in that person's knowledge... not
saying there won't be bugs, but you shouldn't commit incomplete changes).
3. I don't think we need to branch as these changes could be made directly
to HEAD.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
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]>
