The initial list of components I have are:
Requried By Aspects:
Required By EJB3
JMS (new or jbossmq?)
Required By WEB
This list needs to be tightened up.
I have created two releases in the JBAS project:
JBossPOJOServer-1.0 Alpha Release date 28/Feb/2005
JBossPOJOServer-1.0 Final Release date 30/May/2005
I probably misunderstood this which is where my disconnect is,
I thought the plan was to create the POJO server as a standalone project.
With JBossAS migrating later to be the full j2ee stack on top of it?
They will eventually be the same thing.
I would view the pojo server as a component of the app server. It will have standalone releases. I guess I'm leary of project explosion just causing confusion. Is there an ease of management argument for a seperate pojo server project?
No ease of management that I'm aware of, it is just how the project
was described to me originally.
It might be an idea to split out some of the integration points
so they are available more a la carte
e.g. At the moment they are mostly defined in the server module (along with some implementations like cmp or mdb).
Obvious candidates in the server module are:
invokers/proxy -> remoting
invocation -> aop/microcontainer?
container -> aop/microcontainer (if we really want to bother/risk migrating EJB2 to the new container)
server/security -> security
jmx -> management/jsr160
server/jndi -> naming
Although in general my preference is to have the integeration point
in a separate module to the implementations.
e.g. Both the connector and transaction modules define the
interfaces, management, implementation and helper classes
meaning the integration is ill defined and suspectible to being broken by
people who don't understand the abstraction.
This is abstraction is further complicated when a module has a client component.
The existing server module certainly needs to be split up and the suggested breakup makes sense. However, the only time there is an associated jira project for a cvs module(s) is if we are releasing it as a standalone product. I'm still confused as to how the refactoring of the legacy app server is being reflected in jira. Until that's clear, let's just go with the JBAS project JBossPOJOServer-1.0 versions as the container for the associated roadmap tasks.
Isn't that the JBossPOJO Server is really JBossAS 5 (over the JBoss MicroContainer), where there will be more freedom in combing components.
In this sense, why change name/version scheme?
In which case a JBossPOJO server will be offered standalone and not be named JBossAS?
If this is confusing to us, imagine how it'll be perceived by the users..
Yes, there will be a non-JBossAS release of the POJO server that does not include the full j2ee related services. The confusion is not in the names, its in what the associated jira project is.
FYI: Aspects/EJB3 requires clustering as it uses the replicant manager and a few other services that are in clustering.
EJB3 does require Server because it reuses the EJB TImer service.
At some point during the JBoss5 development I will work through
these depdencies so we can take the functionality in more manageable chunks.