You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/01/12 01:21:16 UTC
Branching for Avalon Update
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.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Branching for Avalon Update
Posted by Serge Knystautas <se...@lokitech.com>.
Thanks Steve, comments below.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
> 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)
The 2. points are what I was really looking for and seem like it's
worthwhile. As for 3. points (and maybe even 1), I don't think these are
very relevant to the James community. I understand the benefit of "eating
our own dog food" and using Jakarta and Apache code, but I think James needs
to focus on how it wants to eat it, and not try to factor in how it would
benefit those other communities.
I don't mean this as negative or critical, but with no other library do we
seem to consider support, feedback, or latest-build as a consideration for
upgrading. Certainly not the CVS integration. As Sam said, we could use
Gump against jars instead of direct CVS, and if Avalon didn't branch and
doesn't support an older version, well I think that's more Avalon's problem
than James (I should stop as Noel already did a better job ranting than I
could).
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Branching for Avalon Update
Posted by Stephen McConnell <mc...@apache.org>.
Serge Knystautas wrote:
>----- Original Message -----
>From: "Noel J. Bergman" <no...@devtech.com>
>
>
>
>
>>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Branching for Avalon Update
Posted by "Noel J. Bergman" <no...@devtech.com>.
> 1. I'd like to hear more of the case for upgrading our Avalon components.
Hopefully, Stephen can give us a better overview, but here are some
observations:
a) there are bugs in Avalon code, and currently the only
way to get the fixes is to upgrade our components.
b) there are other Avalon containers, and if we want
James to be able to run in them, as Stephen is
attempting to do, then we need to support the
current interfaces.
> 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.
Yes, I know. They haven't even updated their site documentation to list the
changes, so I would have to pull a CVS log and hope that they are commented.
Which is why I wouldn't even consider changing James v2. But I think that
it makes sense for James v3.
I don't believe that we don't want to be trapped with code that we can't get
bug fixes for, and can't even properly identify the source.
> 2. I don't think whoever is making these changes should commit changes
until
> you have a runnable James
There might be multiple people making those changes, unless Stephen already
has them made. (Peter has, too, so I might be able to get them from him,
but I'd need to refit to James).
> 3. I don't think we need to branch as these changes could be made directly
> to HEAD.
If we can make them in one swoop, without problem, then I agree. I just
want to be safe. I suppose that we could be safe by tagging first, and then
see what happens.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Branching for Avalon Update
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> 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.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>