IMHO, if partially starting the server means that a EAR/WAR/CAR can't be deployed remotely then I don't think that is practical as a user may want to build and deploy the CAR from a GUI PC/workstation (possibly using a GUI deployment tool) to a remote headless server.
Does anyone have a link to some more info about CAR files? I could only find http://java.sun.com/j2ee/1.4/docs/api/javax/enterprise/deploy/shared/ModuleType.html
The CAR Aaron is referring to is a Configuration Archive which is a Geronimo concept and not a J2EE Application Client Archive as described by ModuleType. Sorry for the confusion.
I wrote a long mail summarizing my views on online vs. offline deployment back in Nov that goes into Geronimo packaging:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=9851
The intent behind a (Geronimo) CAR file is that it is a versioned, sealable artifact containing both code and configuration state that can be transported between Geronimo installations. It is the external form of a Configuration, which is a package of services that can be hosted by a Kernel.
A Configuration is startable if its codebase dependencies can be resolved (using the installation's Repository services) and all of the GBeans it contains (defined as a collection of GBeanInfo + GBeanState objects) can be instantiated and brought online in the STOPPED state. Individual GBean inside the Configuration may or may not be startable depending on whether their (service) references are resolvable.
The Kernel only knows about Configuration packages - it has no knowledge of user-land packaging artifacts such as J2EE WARs or EARs. The job of converting user-land artifacts into Configurations is done by a ConfigurationBuilder working in conjunction with a set of ModuleBuilders - the process of doing this is loosely called deployment. The ConfigurationBuilder can be as complex as needed to get this job done - it might be fairly simple like the one for service.xml files, it might be quite complex like the J2EE one.
To build a Configuration, a builder may need access to other Configurations on which the one being build has /code/ level dependencies. For example, to introspect an EJB class the EJB builder would require the javax.ejb.* classes to be available, just like the EJB itself would need them at runtime. Thus during the build process, the builder needs to resolve code dependencies declared by the target Configuration; however, it does not need to resolve /service/ dependencies such as the availability of other GBeans.
This allows "offline" deployment, for example from a PC/Workstation. The intention is that a user can build a (Geronimo) CAR file in that environment, sign, seal and deliver it, handing off to an enterprise configuration management/provisioning process. That same (sealed) CAR file can be sent to any Geronimo server running anywhere in the enterprise (or outside) with confidence that, assuming the necessary code and services are available at that site, it will run as intended.
This is aimed purely and simply at enterprise users who have to deal with a lot of configurations and installations; it is not a model aimed at supporting iterative build/test cycles on a single desktop.
For that we have "online" deployment where a running server actually hosts its own deployment framework. A developer can hand a user-land module and a plan to the server using some mechanism such as Maven or a JSR-88 client, have it build the Configuration in-situ and bring online autoamtically in that local server ready for testing. This, of course, relies on the server being running.
To me this is a fairly simple solution that addresses the different needs of the two communities. However, at this time only online mode really works; although offline mode can generate CAR files, we are missing a way to easily import them into the target server.
-- Jeremy
