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 Stephen McConnell <mc...@apache.org> on 2003/09/18 23:34:03 UTC
is 3.0 a dead branch
I'm currently running an instance of James based on CVS HEAD. Looking
at some of the recent comments on the dev and user lists it appears that
updates are being applied to 2.1/2.2 and that HEAD is now not really
HEAD at all. Should I be dropping 3.0a1 in favour of 2.2 (which I'm not
too keen on since 3.0a1 is totally in sync with all of the latest avalon
releases).
Any comments and/or suggestions about appropriate direction appreciated.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: is 3.0 a dead branch
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>>2. seperation api and impl makes james a more reusable proposition (when
>>> viewing james a compositie component)
>>You are missing the point that the API changed, and code relying upon the
>>new API would not be compatible with the older API. Like how a program
>>requiring java.nio won't work with JDK 1.3.
>Ok so if I underand correctly - 3.0a1 contains JDK 1.4 dependencies and
>that the 2.1/2.2 stuff is based on 1.3.1.
Close. It contains Mailet API dependencies. Things that were internal
became exposed, and it is unclear that we want to preserve those
experimental changes. MAIN is a development branch, not production.
> If that's correct - then in reality the 2.1/2.1 content is what I should
be
> considering as the MAIN branch.
If you mean production, then yes. The v2 branch is the stable production
branch, and MAIN was the development branch.
> However, to get this in sync. we would need to backport all of
> the Componet/Service migration stuff that was put into HEAD way
> back (which is something I'm not looking forward to).
I don't know that it can be helped, except where there the only differences
are the Avalon changes.
> And just to confirm again - the core problem is 1.4 in HEAD versue 1.3
> in MAIN ?
Again, that was an analogy. See above. Basically, the Mailet API in v2
does not expose the repositories. The one in MAIN does, and shuffled other
things around, and it is absolutely not clear that we want to expose some of
the changes that were made. I think we don't, but either way we certainly
don't want to be stuck with it, since we haven't made it as Release.
> james should move to a container neutral build which means some
> restructuring.
If someone wants to do that work, we should. For that matter, if someone
wants to fix a container so that it supports proper logging, it could become
the default container shipped with James (assuming that it passes
functional, load and performance testing).
> I still think/assert that a formal api/impl seperation would be *really*
> valuable in terms of (a) immediate reusability of james subsystems, and
> (b) future initative related to james scalability.
IMO, the published version of Mailet API in a Release is the only public
guarantee. The rest are server internals. And that flexibility is
necessary to ensure future scalability.
> Anyway - I could checkout the MAIN (2.1/2.2? branch) of james and start
> looking at things. Which is the actual CVS tag I should reference?
branch_2_1_fcs is the generic v2 branch, pre-experimental Mailet API
changes.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: is 3.0 a dead branch
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>It would be nice to get to a position where patches are not
>>applied against non-development branches (i.e. only accept
>>patches against HEAD).
>>
>>
>
>The point is that we had two development branches. One based
>upon the current stable API, and the other with some
>experimental changes.
>
>
>
>>What about migration to maven and some restructuring to-boot.
>>
>>
>
>It could happen, but doesn't help.
>
>
>
>>2. seperation api and impl makes james a more reusable proposition (when
>> viewing james a compositie component)
>>
>>
>
>You are missing the point that the API changed, and code relying upon the
>new API would not be compatible with the older API. Like how a program
>requiring java.nio won't work with JDK 1.3.
>
Ok so if I underand correctly - 3.0a1 contains JDK 1.4 dependencies and
that the 2.1/2.2 stuff is based on 1.3.1. If that's correct - then in
reality the 2.1/2.1 content is what I should be considering as the MAIN
branch. However, to get this in sync. we would need to backport all of
the Componet/Service migration stuff that was put into HEAD way back
(which is something I'm not looking forward to).
>>4. because I can help
>>
>>
>
>Makes it worth looking at, but still doesn't help with the core problem.
>
And just to confirm again - the core problem is 1.4 in HEAD versue 1.3
in MAIN ?
>>Somewhat off-topic but releated to James is some work I've been doing
>>recently on the openim project. Alexis (the guy heading up all of this)
>>has been reusing james components as part of work on getting a user
>>object model in place.
>>
>>
>
>I have been trying to get Alexis to bring that code here, and make it a
>James sub-project to integrate as a new service in the server, but he hasn't
>taken up on it.
>
Currently we (openim) are working against James HEAD - so irrespective
of where core is resident - we need to close the question of the
reference branch. Something else to keep in mind is the openim is
running against Merlin 3.0 (which ties into my note about seperating the
james build from specific containment dependencies - i.e. some
restructuring is justified - the dependency in openim are actually with
Avalon Meta 1.1 which is under a PMC vote but Avalon Meta is not
supported by Phoenix but is supported in Merlin 3.0). Thing is that
james should move to a container neutral build which means some
restructuring.
>>the openim/james work has been hampered by a lack of api/impl seperation
>>on the individual james components (for example - to reuse the user
>>repository the solution ends up being dependent on the mailet impl
>>classes, activation.jar and mail-1.3.1.jar - which is kind of icky).
>>
>>
>
>That will change when we switch to using JNDI for the user repository. I've
>started to prototype that here, which is one reason I'd like to clean up the
>branch split.
>
I still think/assert that a formal api/impl seperation would be *really*
valuable in terms of (a) immediate reusability of james subsystems, and
(b) future initative related to james scalability.
>>You may want to take a look at the merlin website. Its totally
>>generated via a maven based build. Site updating and distribution
>>building is now almost trivial (ie. around 5 mins for a totally new
>>site and distribution archive).
>>
>>
>>
>Building ours is trivial, too. The problem is that it is in two branches.
>We need to move it into the james-site module, and adjust the build process
>accordingly. That said, we have looked at both Maven and Forrest (perhaps
>Maven with Forrest doing the actual rendering), but no one has stepped
>forward to do that work.
>
Maven site builds are working well for me whereas forrest is failing in
cases I'm associated with - and I'm not seeing sufficient support from
the forrest community to consider it as a viable alternative at this
time. But this is not not a issue for me because I'm not building james
doc (just linking to it).
Anyway - I could checkout the MAIN (2.1/2.2? branch) of james and start
looking at things. Which is the actual CVS tag I should reference?
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: is 3.0 a dead branch
Posted by "Noel J. Bergman" <no...@devtech.com>.
> It would be nice to get to a position where patches are not applied
against
> non-development branches (i.e. only accept patches against HEAD).
The point is that we had two development branches. One based upon the
current stable API, and the other with some experimental changes.
> What about migration to maven and some restructuring to-boot.
It could happen, but doesn't help.
> 2. seperation api and impl makes james a more reusable proposition (when
> viewing james a compositie component)
You are missing the point that the API changed, and code relying upon the
new API would not be compatible with the older API. Like how a program
requiring java.nio won't work with JDK 1.3.
> 4. because I can help
Makes it worth looking at, but still doesn't help with the core problem.
> Somewhat off-topic but releated to James is some work I've been doing
> recently on the openim project. Alexis (the guy heading up all of this)
> has been reusing james components as part of work on getting a user
> object model in place.
I have been trying to get Alexis to bring that code here, and make it a
James sub-project to integrate as a new service in the server, but he hasn't
taken up on it.
> the openim/james work has been hampered by a lack of api/impl seperation
> on the individual james components (for example - to reuse the user
> repository the solution ends up being dependent on the mailet impl
> classes, activation.jar and mail-1.3.1.jar - which is kind of icky).
That will change when we switch to using JNDI for the user repository. I've
started to prototype that here, which is one reason I'd like to clean up the
branch split.
> You may want to take a look at the merlin website. Its totally generated
via
> a maven based build. Site updating and distribution building is now
almost
> trivial (ie. around 5 mins for a totally new site and distribution
archive).
Building ours is trivial, too. The problem is that it is in two branches.
We need to move it into the james-site module, and adjust the build process
accordingly. That said, we have looked at both Maven and Forrest (perhaps
Maven with Forrest doing the actual rendering), but no one has stepped
forward to do that work.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: is 3.0 a dead branch
Posted by Stephen McConnell <mc...@apache.org>.
Noel:
Notes in line.
Noel J. Bergman wrote:
>No, it isn't dead. I've been consumed on some other things, and no one else
>has been merging changes into MAIN.
>
>
It would be nice to get to a position where patches are not applied against
non-development branches (i.e. only accept patches against HEAD).
>In some cases, we've had patches submitted that there done in such manner as
>to be more work (new files should be submitted as files, not embedded in the
>diff), and I haven't had time. Vincenzo has been on vacation, and others
>have been consumed.
>
I completely understand.
>
>HOWEVER, getting to one of your points, since v2.2 is not v2.1, I would like
>to get it into sync with the latest Avalon Release, and make that part of
>the v2.2.0 Release.
>
(was about to ask a question that you answered in the next para.)
>
>My proposal has been that we bring v2.2 up to date with the latest Avalon
>code, make ONLY such changes to the Mailet API that we really are SURE that
>we want to keep, put the remainder in an experimental branch, and merge v2.2
>back into MAIN.
>
This sounds like a plan.
>If I recall correctly, the only desired differences between
>v2.2 are the Avalon changes and those experimental Mailet API changes. I
>think we'd like to keep all of the good work that was done on the build
>process in MAIN, rather than revert to the older approach in the v2 branch.
>
Here is a radical suggestion (i.e. feel free to ignore this).
What about migration to maven and some restructuring to-boot. As you
know, cornerstone etc. has been broken out into maven based builds
including clean seperation of api and implemetation. The head build.xml
contains a hack apprach at doing the same thing on the mailet and james
jar files (I'm allowed to call it a hack becuase I introducted it). I
guess what I'm thinking about - is a seperation fo the james project
into a series of subprojects (DNS, SMTP, POP3, etc. - where each
subproject contains an api and impl subproject). Now you probably
thinking to yourself "ohh, no - more work - why", well, here are the
reasons:
1. moving to maven makes things easier to maintain
2. seperation api and impl makes james a more reusable proposition (when
viewing james a compositie component)
3. enables seperation of james from container build/packaging dependencies
(which also addresses the possibility for the coexistance of multiple
deployment solutions - Phoenix or Merlin)
4. because I can help
Somewhat off-topic but releated to James is some work I've been doing
recently on the openim project. Alexis (the guy heading up all of this)
has been reusing james components as part of work on getting a user
object model in place. OK - this is all in the context of Merlin but
the point is that under merlin the reuse of blocks is much higher simply
because components parts can be seperated out and packaged. Even so -
the openim/james work has been hampered by a lack of api/impl seperation
on the individual james components (for example - to reuse the user
repository the solutioin ends up being dependent on the mailet impl
classes, activation.jar and mail-1.3.1.jar - which is kind of icky).
However - aside from that, we are now down to an openim install process
that is about three command line arugments (one of which takes care of
te james installation).
>
>
>Doing this would reduce the maintenance overhead, give me a clean base to
>start adding the JNDI code, and make it a darned sight easier to keep the
>Web-site up to date.
>
You may want to take a look at the merlin website. Its totally generated via
a maven based build. Site updating and distribution building is now almost
trivial (ie. around 5 mins for a totally new site and distribution
archive).
Cheers, Steve.
>
> --- Noel
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@apache.org]
>Sent: Thursday, September 18, 2003 17:34
>To: James Developers List
>Subject: is 3.0 a dead branch
>
>I'm currently running an instance of James based on CVS HEAD. Looking
>at some of the recent comments on the dev and user lists it appears that
>updates are being applied to 2.1/2.2 and that HEAD is now not really
>HEAD at all. Should I be dropping 3.0a1 in favour of 2.2 (which I'm not
>too keen on since 3.0a1 is totally in sync with all of the latest avalon
>releases).
>
>Any comments and/or suggestions about appropriate direction appreciated.
>
>Cheers, Steve.
>
>--
>
>Stephen J. McConnell
>mailto:mcconnell@apache.org
>
>
>
>
>---------------------------------------------------------------------
>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
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: is 3.0 a dead branch
Posted by "Noel J. Bergman" <no...@devtech.com>.
No, it isn't dead. I've been consumed on some other things, and no one else
has been merging changes into MAIN.
In some cases, we've had patches submitted that there done in such manner as
to be more work (new files should be submitted as files, not embedded in the
diff), and I haven't had time. Vincenzo has been on vacation, and others
have been consumed.
HOWEVER, getting to one of your points, since v2.2 is not v2.1, I would like
to get it into sync with the latest Avalon Release, and make that part of
the v2.2.0 Release.
My proposal has been that we bring v2.2 up to date with the latest Avalon
code, make ONLY such changes to the Mailet API that we really are SURE that
we want to keep, put the remainder in an experimental branch, and merge v2.2
back into MAIN. If I recall correctly, the only desired differences between
v2.2 are the Avalon changes and those experimental Mailet API changes. I
think we'd like to keep all of the good work that was done on the build
process in MAIN, rather than revert to the older approach in the v2 branch.
Doing this would reduce the maintenance overhead, give me a clean base to
start adding the JNDI code, and make it a darned sight easier to keep the
Web-site up to date.
--- Noel
-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@apache.org]
Sent: Thursday, September 18, 2003 17:34
To: James Developers List
Subject: is 3.0 a dead branch
I'm currently running an instance of James based on CVS HEAD. Looking
at some of the recent comments on the dev and user lists it appears that
updates are being applied to 2.1/2.2 and that HEAD is now not really
HEAD at all. Should I be dropping 3.0a1 in favour of 2.2 (which I'm not
too keen on since 3.0a1 is totally in sync with all of the latest avalon
releases).
Any comments and/or suggestions about appropriate direction appreciated.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
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