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