Hi Jason! A little history ---------------- Current state of affairs: we're in a mess (once more). Looking at the history of our CVS modules you'll definately scratch your head.
We started out with a single CVS (just jakarta-avalon). Since there were some conceptually separate modules (lifecycle, logkit, phoenix, cornerstone) they were split off (lifecycle becoming framework). When the Cocoon people came along lots of stuff was moved from cocoon to avalon (like ECM). We created a new repository for all that: excalibur. (there shouldn't have been a release of ECM, we now all agree on, but cocoon needed it...so many components were released to go with it because excalibur was one jar file) At one point in the past, we had the problem that *components* written for ECM were completely different from *blocks* written for phoenix. We put blocks inside cornerstone and the components inside the excalibur module. Next issue: there's only a thin line between the concept of a phoenix block and a complete application. We discussed this and moved what we felt were complete applications into a new CVS module: apps. Most of the activity right now is inside excalibur CVS; it is growing to a very inconvenient size atm. What is happening now is that components that can work outside of avalon are moved to commons, to slim excalibur down again. What I see happening -------------------- Just like it was inconvenient to have phoenix (container) and blocks that run in it (components) inside the same module, it is inconvenient to have ecm/fortress/etc inside the same module as the components that run in it. The logical thought is that we'd have excalibur for the components, and jakarta-avalon-containers (or something) for our containers. Since we're seeing convergence between phoenix and the other containers, and hence between blocks and components, we're not going to do that. Instead, I think stuff like ECM, fortress, merlin, tweety (containers) will stay in excalibur, as well as container-related materials (containerkit) and stuff-that-could-be-in-framework-at-some-point (like the Event packages; because this stuff is usually tightly coupled to containers); we might even see phoenix move to excalibur as well (as it is a container too). All components in excalibur that cannot move to commons will move to cornerstone; all components/blocks that are so big they can be considered applications on their own stay in apps. In that scenario, a catalina wrapper seems like it should be in apps as well (in reality, it should be part of the tomcat project, but that's not going to happen anytime soon). This is all just IMO and there is no agreement on any of it....<rest of standard disclaimer here> Guideline --------- If it listens on a port or uses sockets, it is likely to be an application. Otherwise, it is likely to be a component. Put your applications in avalon-apps, your components inside cornerstone or excalibur. To answer more directly ----------------------- > Is there any reason in particular things like Sevak go into Phoenix and > aren't just normal components? they go into avalon-apps, which used to be things that only phoenix could handle well. This is changing; the majority of the applications in avalon-apps could easily work in fortress (I think all of them can work within merlin). > I want a servlet container component but > I'm not running phoenix. Looking at it I could easily strip out phoenix > references and make it work in fortress or my tweety mutant. would be neat. Tweety mutant....makes me think of Bigbird.... > Is there any reason there couldn't be phoenix wrappers for things like > Sevak. ouch. We should not need wrappers! > Sevak in particular seems out of place because as something like > Sevak might be assembled into something larger to form an application > but isn't an application itself. hmm. Catalina is often used as an application in itself. > Will the common metadata/containerkit work allow for there to be more > standard components? yes. - Leo Simons -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
