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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
