Leo Simons wrote:
...
> 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).
+1
> 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>
What really makes me uneasy is the fact that we have multiple
definitions of components.
classes
excalibur components
blocks
server apps (.sar)
Simply put, this is what I *want*
classes -> commons
blocks -> cornerstone
server apps -> apps
of course:
containers -> excalibur
We *must* have a single way of defining components, and I want to see
blocks and components unite.
> 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.
Hmmm...
For me applications are .sar files.
> Put your applications in avalon-apps,
+1
>your components inside cornerstone
> or excalibur.
Cornerstone.
keep excalibur for containers.
> 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).
We *will* have a single component model. Period.
The only question is how, but it's getting resolved.
>>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....
hehehe
>>Is there any reason there couldn't be phoenix wrappers for things like
>>Sevak.
>
> ouch. We should not need wrappers!
+1 no 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.
For me it should be refactored in 1 or more Component-Blocks.
Then we would have
-catalina component
-coyote component
-...
and
-sevak .sar
etc...
>>Will the common metadata/containerkit work allow for there to be more
>>standard components?
>
> yes.
Yes :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
