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 Robert Burrell Donkin <ro...@gmail.com> on 2008/03/03 23:46:55 UTC
2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
On Mon, Mar 3, 2008 at 9:41 PM, Noel J. Bergman <no...@devtech.com> wrote:
> Robert,
>
> It sounds OK, so +1 in general, but with all of the refactoring, we've
> making it increasingly difficult to compare versions of JAMES. This would
> not be so bad if we had ever made a stable baseline prior to the
> refactorings, but instead we started with unstable baselines and refactored,
> meaning that we will have to do considerable manual comparison between the
> only known stable JAMES code (2.3.0) with its known defects and the current
> trunk(s) for JAMES and Mailets.
trunk was forked from 2.3.0 several years ago now and contains
significant differences not only in organisation but also design. i
doubt whether anyone has the time required to perform a comprehensive
manual comparison now whether the mailets are in trunk or elsewhere.
i think that moving the mailets into a separate project should make
things move managable. the mailets moved can be compared with 2.3.x
and (once this has been done) a single consolidated library can used
for both 2.x and 3.x releases (as well as trunk).
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> trunk was forked from 2.3.0 several years ago now and contains
> significant differences not only in organisation but also design. i
> doubt whether anyone has the time required to perform a comprehensive
> manual comparison now whether the mailets are in trunk or elsewhere.
+1
> i think that moving the mailets into a separate project should make
> things move managable. the mailets moved can be compared with 2.3.x
> and (once this has been done) a single consolidated library can used
> for both 2.x and 3.x releases (as well as trunk).
IIRC mailet API currently used by trunk shown few differences from the
mailet api distributed with 2.3.x. I'm not sure we'll be able to create
a single package for both "branches" (But this should be confirmed
comparing mailet api sources).
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Mailet changes (Was: 2.3.x vs trunk)
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Robert Burrell Donkin wrote:
>> i think that moving the mailets into a separate project should make
>> things move managable.
>
> In the long run, I agree. Even in the mid-term, we can compare the Mailets
> in the new project with those in the release, and validate the changes.
I agree this should be done. We have a mailet project and changes
between mailet v2.3 and current trunk mailet are minor.
>> a single consolidated library can used for both 2.x and 3.x releases (as
> well as trunk).
>
> We'll may have to make some changes to allow that, since people didn't treat
> the code in a manner that would ensure this simple statement. This would be
> another benefit from your proposal. Separating the Mailet library from the
> server would discourage people from changing them in lockstep.
"people didn't treat the code.... "? Whom? What changes?
Every single change we did in trunk mailets has been discussed in the
mailing list. Most changes we did from 2.2.0 to 2.3.0 was to make sure
some JAMES specific mailets could be made generic mailets (e.g: we moved
some method from MailImpl to Mail in order to remove every cast to
MailImpl in mailets).
Here is instead a list of changes between mailet released in 2.3.0 and
current mailet trunk code:
GenericMailet
- altered default logging to include mailet name
+ added checkInitParameters and arrayToString methods
GenericMatcher
- altered default logging to include mailet name
MailAddress
- constructor throws AddressException instead of ParseException
- other changes by danny:
http://svn.apache.org/viewvc?view=rev&revision=565772
http://issues.apache.org/jira/browse/MAILET-7
MailetContext
- isLocalUser now expect a full email address. if no @ is there then
@localhost is appended for the check.
+ added isLocalEmail
As you can see changes are very limited and maybe the only issue that
should be better checked is the MailAddress compatibility. Every other
change since 2.3.0 seems to be backward compatible (I would say both
binary and source compatible)
> That said, we want to be able to evolve the Mailet API, in a controlled and
> proper manner.
>
> --- Noel
+1
we created mailet-api@ list, the mailet svn tree and the mailet jira
because of this.
Feel free to use one of this tools in order to discuss about your
specific concerns about current mailet sources!
I cross post to mailet-api so we can continue there.
Stefano
Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> JAMES uses LogKit (and so avalon framework) for logging. though LogKit
> is good, it's tied to avalon and no longer widely used. most
> developers would be much more familiar with log4j and JCL. it is
> possible to use either of these libraries in an IoC fashion which
> would continue to support area based logging.
For the record I prefer avalon-framework logging interfaces to JCL and
log4j. Avalon's one is the only dependency injection based logging
framework and IMHO much better than JCL and log4j.
It is easy to use log4j or JCL implementations via the avalon interfaces
while it is not easy to do the opposite.
> JAMES has it's own bio framework based on excalibur (which is alive)
> but we've done a poor job of clearly factoring it out cleanly from
> avalon. this would not matter so much if it used delegation rather
> than inheritance.
I agree.
> many of the JAMES backends are implemented using avalon components
I agree.
>> A major area to look at is configuration.
>
> use of avalon as our IoC container is a major issue. we can't hide it.
> there's no spinning it. any developer who wants to code anything new
> or interesting (rather than just maintaining the existing codebase)
> has to learn avalon. this is proves too big hurdle for most.
true
> as far as IoC containers go, Avalon is definitely showing it's age: it
> relies on far too many configuration files and assembling components
> takes too much legroom. use of avalon to assemble JAMES might be
> usefully replaced by OSGI.
It is not avalon framework that depends on so many configuration files
but the specific container we use (phoenix). That said I agree that
Avalon framework "Configuration" interface is not so good and it would
be better to move to something better. I'm not sure that OSGi will
decrease the needed configuration files and metadata. For my experience
OSGi instead increase it: but it is possible I used it the wrong way.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Mar 6, 2008 at 6:49 AM, Noel J. Bergman <no...@devtech.com> wrote:
> Robert Burrell Donkin wrote:
<snip>
> > i'm happy with avalon but i accept that using avalon (as an IoC) is
> > a major negative factor in attracting new developers
>
> I think that's a false truth that has become a meme. Drop the name Avalon,
> say that JANES has its own infrastructure, and the "Avalon is dead" nonsense
> goes away. Although we can and should continue the pojofication of JAMES
> over time.
avalon is dead. we killed it. that's not a meme or nonsense but a fact.
to say that JAMES has it's own infrastructure is not entirely true:
once a developer starts looking at the code, the falsehood will
quickly become exposed. i'll go through some areas.
JAMES uses LogKit (and so avalon framework) for logging. though LogKit
is good, it's tied to avalon and no longer widely used. most
developers would be much more familiar with log4j and JCL. it is
possible to use either of these libraries in an IoC fashion which
would continue to support area based logging.
JAMES has it's own bio framework based on excalibur (which is alive)
but we've done a poor job of clearly factoring it out cleanly from
avalon. this would not matter so much if it used delegation rather
than inheritance.
many of the JAMES backends are implemented using avalon components
> A major area to look at is configuration.
use of avalon as our IoC container is a major issue. we can't hide it.
there's no spinning it. any developer who wants to code anything new
or interesting (rather than just maintaining the existing codebase)
has to learn avalon. this is proves too big hurdle for most.
as far as IoC containers go, Avalon is definitely showing it's age: it
relies on far too many configuration files and assembling components
takes too much legroom. use of avalon to assemble JAMES might be
usefully replaced by OSGI.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Robert Burrell Donkin wrote:
> releasing a 3.0 would involve a series of milestone releases to
> build confidence in the new codebase rather than a manual process
> of re-evaluating every change.
Re-evaluating implies that they were evaluated in the first place.
> i hope to have a function complete IMAP4rev2 working in time for
> ApacheConEU. we could aim to create an initial 3.0 technology
> preview then.
I'll look forward to sitting with you Monday afternoon, and anytime that
isn't Tuesday.
> i'm happy with avalon but i accept that using avalon (as an IoC) is
> a major negative factor in attracting new developers
I think that's a false truth that has become a meme. Drop the name Avalon,
say that JANES has its own infrastructure, and the "Avalon is dead" nonsense
goes away. Although we can and should continue the pojofication of JAMES
over time.
A major area to look at is configuration. This is as much, if not more so,
for the Mailet API as for internal interfaces. For Mailets, I'm strongly
leaning towards annotations, but there's more to this area than just
declaring injectors.
> excluding IMAP+deployment, the only change that springs to mind are
> the JAMES handler framework improvements. if inheritance were to be
> replaced by delegation for this framework then most modules would have
> very few changes.
Sounds like the start of a discussion.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Mar 5, 2008 at 10:37 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Noel J. Bergman ha scritto:
>
> > Robert Burrell Donkin wrote:
> >> trunk was forked from 2.3.0 several years ago now
> >
> > Yes, I am keenly aware of the last time I had time to work on a release and
> > the communal disinterest or inability to do one since. One question I have
> > is, should the next release come from a v2.3.0 follow-on, or should we even
> > attempt to extricate something from trunk. And if the latter, then we are
> > going to have to compare that against the known, good, codebase. And, yes,
> > as the person who did this the last time, I'm well aware of the effort
> > involved. Hence my question and concerns.
>
> Are you referring to the merge between trunk and 2.2.0 code between 2004
> and 2005 ? I think it is a different story. That branch involved much
> less code than current v2.3-trunk differences but included major changes
> to mailet api.
>
> I don't agree that the only way to produce quality is to compare with
> previous work. The fact that you don't know what is in trunk because you
> had no time to review most commits doesn't mean that this is the same
> for everyone else here.
+1
releasing a 3.0 would involve a series of milestone releases to build
confidence in the new codebase rather than a manual process of
re-evaluating every change. i hope to have a function complete
IMAP4rev2 working in time for ApacheConEU. we could aim to create an
initial 3.0 technology preview then.
IMHO the major remaining task to be tackled for 3.0 is to revise the
application assembly. i'm happy with avalon but i accept that using
avalon (as an IoC) is a major negative factor in attracting new
developers for a variety of reasons. i think JAMES needs a new
micro-kernel architecture.
> IMO there is no need at all to merge v2.3 and trunk this time. This time
> we had no single fix in v2.3 that has not been done in trunk too. We
> have been very diligent and we avoided diverging branches so to not
> repeat the post-2.2.0 mistakes.
>
> If you need time to check code quality in trunk, well, take your time
> and let's discuss about specific code.
> If you think it doesn't worth your time then start working on v2.3 and
> make a proposal from there.
+1
> >> contains significant differences not only in organisation but also design.
> >> i doubt whether anyone has the time required to perform a comprehensive
> >> manual comparison now whether the mailets are in trunk or elsewhere.
> >
> > Well, that's part of the issue. Due to the reorg, we will be hard pressed
> > to compare the changes in the current code from the released code.
>
> If you exclude IMAP most code has changed BEFORE the code
> reorganization. So it should be easier than you think. You will see that
> since dicember 2006 we had very limited changes in the sources (if you
> exclude IMAP and its dependencies).
> It is a lot of code, because we implemented a lot of features and fixed
> a lot of long standing issues in our services API.
excluding IMAP+deployment, the only change that springs to mind are
the JAMES handler framework improvements. if inheritance were to be
replaced by delegation for this framework then most modules would have
very few changes.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by Bernd Fondermann <be...@googlemail.com>.
On Thu, Mar 6, 2008 at 2:38 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Noel J. Bergman ha scritto:
>
> > Stefano Bagnara wrote:
> >> I think it is a different story. That branch involved much less code than
> >> current v2.3-trunk differences but included major changes to mailet api.
> >
> > Yes, much less code. More code ==> more bugs. And you certainly aren't
> > going to claim that there aren't major changes in trunk from the known-good
> > code.
>
> Let's start collecting bugs in JIRA and start solving some of them. We
> keep talking about how unstable is trunk and how many bugs are in trunk,
> but we don't have bugs reported against that code.
> We are discussing too much about what it "could be" and we should use
> our limited time to work on concrete things.
> If we'll collect too many critical/problematic bugs against trunk we may
> agree more easily that v2.3 is the way to go and that trunk should be
> discarded, don't you think?
emphatical +1!
collecting bugs means testing what we have. acutally running the code.
based on 2.3.1 or trunk, as you like.
then we can document in JIRA, discuss, write unit or functional tests
to reproduce and improve.
we can even review and discuss specific commits without having a bug.
everything else is a complete waste of time.
Bernd
>
>
> >> The fact that you don't know what is in trunk because you had no time to
> >> review most commits doesn't mean that this is the same for everyone else
> >> here.
> >
> > Actually, (a) you have no idea what I review, and (b) I will bet you that
> > almost no one is reviewing a fraction of the commits. That's part of our
> > dysfunction as a community. Out of Serge, Danny, myself, Vincenzo, Soren,
> > Steve, Norman, Robert, Bernd and anyone else whom I've missed, how many
> > pairs of eyes do you believe are reviewing each commit? My guess is 2-3,
> > tops, on average, including the committer.
>
> (a) VERY TRUE. Tell us.
> (b) VERY TRUE: this is true since JAMES project has been created. Or at
> least is true since I'm here (2005).
>
> We need to cut milestones and do releases if we want people to use that
> code and increase our confidence on the code quality.
>
>
> >> IMO there is no need at all to merge v2.3 and trunk this time.
> >
> > I agree with you, but who suggested such a thing?
>
> Good then. Recorded. No need to merge. (it was probably a
> misunderstanding on my side.. )
>
>
> >> This time we had no single fix in v2.3 that has not been done in trunk
> > too.
> >
> > It isn't a matter of what is fixed in trunk. Hey, every appropriate fix
> > that went into MS-Windows XP went into MS-Windows Vista, too, but that
> > doesn't make MS-Windows Vista any less a diasterous load of digital garbage.
> > For that matter, I am currently testing Ubuntu 7.10 and 8.04. Guess what?
> > The new kernel in 8.04 (still Alpha) has major functional regressions
> > compared to 7.10. New code, new designs, new bugs.
>
> During v2.3 development also happened the opposite thing: new code, new
> design, old buggy code no more used ;-)
> But again, this is theory: let's collect the bugs and let's see if we
> have men-power to fix them or not.
>
>
> >> If you exclude IMAP most code has changed BEFORE the code reorganization.
> >> So it should be easier than you think. You will see that since dicember
> > 2006
> >> we had very limited changes in the sources (if you exclude IMAP and its
> >> dependencies). It is a lot of code, because we implemented a lot of
> >> features and fixed a lot of long standing issues in our services API.
> >
> > So you propose that we first vet v2.3.0 against a pre-reorg revision of
> > trunk, and then compare the current trunk against the first post-reorg
> > revision?
> >
> > --- Noel
>
> I just suggested you a simpler way to work around the problem you
> described (reorganization make it difficult to compare). I don't need
> this check for myself.
>
> Let us know what are your conclusions/ideas once you'll have checked the
> code.
>
> Thank you,
> Stefano
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Stefano Bagnara wrote:
>> I think it is a different story. That branch involved much less code than
>> current v2.3-trunk differences but included major changes to mailet api.
>
> Yes, much less code. More code ==> more bugs. And you certainly aren't
> going to claim that there aren't major changes in trunk from the known-good
> code.
Let's start collecting bugs in JIRA and start solving some of them. We
keep talking about how unstable is trunk and how many bugs are in trunk,
but we don't have bugs reported against that code.
We are discussing too much about what it "could be" and we should use
our limited time to work on concrete things.
If we'll collect too many critical/problematic bugs against trunk we may
agree more easily that v2.3 is the way to go and that trunk should be
discarded, don't you think?
We need a proof that trunk is really unstable. I always remember that
working on 2.3 most bugs where in the old code and not in the new code,
so we cannot simply say that old code is stable/good and new code is not
stable good. E.g: we wrote unit tests for a lot of the new code, old
code is not unit tested.
>> The fact that you don't know what is in trunk because you had no time to
>> review most commits doesn't mean that this is the same for everyone else
>> here.
>
> Actually, (a) you have no idea what I review, and (b) I will bet you that
> almost no one is reviewing a fraction of the commits. That's part of our
> dysfunction as a community. Out of Serge, Danny, myself, Vincenzo, Soren,
> Steve, Norman, Robert, Bernd and anyone else whom I've missed, how many
> pairs of eyes do you believe are reviewing each commit? My guess is 2-3,
> tops, on average, including the committer.
(a) VERY TRUE. Tell us.
(b) VERY TRUE: this is true since JAMES project has been created. Or at
least is true since I'm here (2005).
We need to cut milestones and do releases if we want people to use that
code and increase our confidence on the code quality.
>> IMO there is no need at all to merge v2.3 and trunk this time.
>
> I agree with you, but who suggested such a thing?
Good then. Recorded. No need to merge. (it was probably a
misunderstanding on my side.. )
>> This time we had no single fix in v2.3 that has not been done in trunk
> too.
>
> It isn't a matter of what is fixed in trunk. Hey, every appropriate fix
> that went into MS-Windows XP went into MS-Windows Vista, too, but that
> doesn't make MS-Windows Vista any less a diasterous load of digital garbage.
> For that matter, I am currently testing Ubuntu 7.10 and 8.04. Guess what?
> The new kernel in 8.04 (still Alpha) has major functional regressions
> compared to 7.10. New code, new designs, new bugs.
During v2.3 development also happened the opposite thing: new code, new
design, old buggy code no more used ;-)
But again, this is theory: let's collect the bugs and let's see if we
have men-power to fix them or not.
>> If you exclude IMAP most code has changed BEFORE the code reorganization.
>> So it should be easier than you think. You will see that since dicember
> 2006
>> we had very limited changes in the sources (if you exclude IMAP and its
>> dependencies). It is a lot of code, because we implemented a lot of
>> features and fixed a lot of long standing issues in our services API.
>
> So you propose that we first vet v2.3.0 against a pre-reorg revision of
> trunk, and then compare the current trunk against the first post-reorg
> revision?
>
> --- Noel
I just suggested you a simpler way to work around the problem you
described (reorganization make it difficult to compare). I don't need
this check for myself.
Let us know what are your conclusions/ideas once you'll have checked the
code.
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> I think it is a different story. That branch involved much less code than
> current v2.3-trunk differences but included major changes to mailet api.
Yes, much less code. More code ==> more bugs. And you certainly aren't
going to claim that there aren't major changes in trunk from the known-good
code.
> I don't agree that the only way to produce quality is to compare with
> previous work.
The only way? No. Total disregard? No to that, too.
> The fact that you don't know what is in trunk because you had no time to
> review most commits doesn't mean that this is the same for everyone else
> here.
Actually, (a) you have no idea what I review, and (b) I will bet you that
almost no one is reviewing a fraction of the commits. That's part of our
dysfunction as a community. Out of Serge, Danny, myself, Vincenzo, Soren,
Steve, Norman, Robert, Bernd and anyone else whom I've missed, how many
pairs of eyes do you believe are reviewing each commit? My guess is 2-3,
tops, on average, including the committer.
> IMO there is no need at all to merge v2.3 and trunk this time.
I agree with you, but who suggested such a thing?
> This time we had no single fix in v2.3 that has not been done in trunk
too.
It isn't a matter of what is fixed in trunk. Hey, every appropriate fix
that went into MS-Windows XP went into MS-Windows Vista, too, but that
doesn't make MS-Windows Vista any less a diasterous load of digital garbage.
For that matter, I am currently testing Ubuntu 7.10 and 8.04. Guess what?
The new kernel in 8.04 (still Alpha) has major functional regressions
compared to 7.10. New code, new designs, new bugs.
> If you exclude IMAP most code has changed BEFORE the code reorganization.
> So it should be easier than you think. You will see that since dicember
2006
> we had very limited changes in the sources (if you exclude IMAP and its
> dependencies). It is a lot of code, because we implemented a lot of
> features and fixed a lot of long standing issues in our services API.
So you propose that we first vet v2.3.0 against a pre-reorg revision of
trunk, and then compare the current trunk against the first post-reorg
revision?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Robert Burrell Donkin wrote:
>> trunk was forked from 2.3.0 several years ago now
>
> Yes, I am keenly aware of the last time I had time to work on a release and
> the communal disinterest or inability to do one since. One question I have
> is, should the next release come from a v2.3.0 follow-on, or should we even
> attempt to extricate something from trunk. And if the latter, then we are
> going to have to compare that against the known, good, codebase. And, yes,
> as the person who did this the last time, I'm well aware of the effort
> involved. Hence my question and concerns.
Are you referring to the merge between trunk and 2.2.0 code between 2004
and 2005 ? I think it is a different story. That branch involved much
less code than current v2.3-trunk differences but included major changes
to mailet api.
I don't agree that the only way to produce quality is to compare with
previous work. The fact that you don't know what is in trunk because you
had no time to review most commits doesn't mean that this is the same
for everyone else here.
IMO there is no need at all to merge v2.3 and trunk this time. This time
we had no single fix in v2.3 that has not been done in trunk too. We
have been very diligent and we avoided diverging branches so to not
repeat the post-2.2.0 mistakes.
If you need time to check code quality in trunk, well, take your time
and let's discuss about specific code.
If you think it doesn't worth your time then start working on v2.3 and
make a proposal from there.
>> contains significant differences not only in organisation but also design.
>> i doubt whether anyone has the time required to perform a comprehensive
>> manual comparison now whether the mailets are in trunk or elsewhere.
>
> Well, that's part of the issue. Due to the reorg, we will be hard pressed
> to compare the changes in the current code from the released code.
If you exclude IMAP most code has changed BEFORE the code
reorganization. So it should be easier than you think. You will see that
since dicember 2006 we had very limited changes in the sources (if you
exclude IMAP and its dependencies).
It is a lot of code, because we implemented a lot of features and fixed
a lot of long standing issues in our services API.
>> i think that moving the mailets into a separate project should make
>> things move managable.
>
> In the long run, I agree. Even in the mid-term, we can compare the Mailets
> in the new project with those in the release, and validate the changes.
I will make a separate reply for mailet issues.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Mailet changes (Was: 2.3.x vs trunk)
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> Robert Burrell Donkin wrote:
>> i think that moving the mailets into a separate project should make
>> things move managable.
>
> In the long run, I agree. Even in the mid-term, we can compare the Mailets
> in the new project with those in the release, and validate the changes.
I agree this should be done. We have a mailet project and changes
between mailet v2.3 and current trunk mailet are minor.
>> a single consolidated library can used for both 2.x and 3.x releases (as
> well as trunk).
>
> We'll may have to make some changes to allow that, since people didn't treat
> the code in a manner that would ensure this simple statement. This would be
> another benefit from your proposal. Separating the Mailet library from the
> server would discourage people from changing them in lockstep.
"people didn't treat the code.... "? Whom? What changes?
Every single change we did in trunk mailets has been discussed in the
mailing list. Most changes we did from 2.2.0 to 2.3.0 was to make sure
some JAMES specific mailets could be made generic mailets (e.g: we moved
some method from MailImpl to Mail in order to remove every cast to
MailImpl in mailets).
Here is instead a list of changes between mailet released in 2.3.0 and
current mailet trunk code:
GenericMailet
- altered default logging to include mailet name
+ added checkInitParameters and arrayToString methods
GenericMatcher
- altered default logging to include mailet name
MailAddress
- constructor throws AddressException instead of ParseException
- other changes by danny:
http://svn.apache.org/viewvc?view=rev&revision=565772
http://issues.apache.org/jira/browse/MAILET-7
MailetContext
- isLocalUser now expect a full email address. if no @ is there then
@localhost is appended for the check.
+ added isLocalEmail
As you can see changes are very limited and maybe the only issue that
should be better checked is the MailAddress compatibility. Every other
change since 2.3.0 seems to be backward compatible (I would say both
binary and source compatible)
> That said, we want to be able to evolve the Mailet API, in a controlled and
> proper manner.
>
> --- Noel
+1
we created mailet-api@ list, the mailet svn tree and the mailet jira
because of this.
Feel free to use one of this tools in order to discuss about your
specific concerns about current mailet sources!
I cross post to mailet-api so we can continue there.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Robert Burrell Donkin wrote:
> Noel J. Bergman wrote:
> > It sounds OK, so +1 in general, but with all of the refactoring, we've
> > making it increasingly difficult to compare versions of JAMES. This
would
> > not be so bad if we had ever made a stable baseline prior to the
> > refactorings, but instead we started with unstable baselines and
refactored,
> > meaning that we will have to do considerable manual comparison between
the
> > only known stable JAMES code (2.3.0) with its known defects and the
current
> > trunk(s) for JAMES and Mailets.
> trunk was forked from 2.3.0 several years ago now
Yes, I am keenly aware of the last time I had time to work on a release and
the communal disinterest or inability to do one since. One question I have
is, should the next release come from a v2.3.0 follow-on, or should we even
attempt to extricate something from trunk. And if the latter, then we are
going to have to compare that against the known, good, codebase. And, yes,
as the person who did this the last time, I'm well aware of the effort
involved. Hence my question and concerns.
> contains significant differences not only in organisation but also design.
> i doubt whether anyone has the time required to perform a comprehensive
> manual comparison now whether the mailets are in trunk or elsewhere.
Well, that's part of the issue. Due to the reorg, we will be hard pressed
to compare the changes in the current code from the released code.
> i think that moving the mailets into a separate project should make
> things move managable.
In the long run, I agree. Even in the mid-term, we can compare the Mailets
in the new project with those in the release, and validate the changes.
> a single consolidated library can used for both 2.x and 3.x releases (as
well as trunk).
We'll may have to make some changes to allow that, since people didn't treat
the code in a manner that would ensure this simple statement. This would be
another benefit from your proposal. Separating the Mailet library from the
server would discourage people from changing them in lockstep.
That said, we want to be able to evolve the Mailet API, in a controlled and
proper manner.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org