Re: What is the point of the CAR file?

[Jason Dillon <ja...@planet57.com>]

My gut still tells me that CAR files should go the way of the Dodo.

W/o CAR's the number of modules for the build is reduced close to  
half, which is a massive simplification IMO.  Also seems that w/o  
CARs then we don't need our custom build plugins, which is another  
significant simplification to the build process.

The need to have code modules, then config modules to build  
configuration state to allow applications to be deployed into the  
server also smells a bit fishy to me.  But, I admit that I really  
don't understand what the benefit of the CAR file is.  From what you  
said David, looks like CAR provides some level of simplification  
inside of the server when dealing with configuration.

Could you (or someone else) please explain what the benefits are in  
more detail.  While, my current thoughts are that we don't really  
need to have it, I would like to understand it before I strengthen my  
recommendation.

  * * *

I'm looking for more details and less debate at this point, so if you  
have a few to explain it I would really appreciate it.

Thanks,

--jason


On Jun 27, 2006, at 11:17 PM, David Jencks wrote:

>
> On Jun 27, 2006, at 3:25 PM, Jason Dillon wrote:
>
>> Can someone briefly explain what the point of CAR files are?
>>
>> They appears to be compiled plan.xml or something... but why do we  
>> need this?  Why not deploy the plan.xml and then let any  
>> processing happen inside of the server... and eliminate the need  
>> for any build-tiime custom CAR mucky muck?
>
> I'm not real enthusiastic about debating this at length right now,  
> but I strongly object to removing the concept of car files.  I'm  
> not thrilled with replaicing the seriailzed gbean content with xml  
> but don't object.  I do object to requiring any builders to be  
> running in a server in order to start any modules.  The idea behind  
> car files is to convert any kind of input configuration info into a  
> basic format that requires no thought to load and run.  Starting  
> with the plan.xml at runtime will require making sure somehow that  
> any builders needed to interpret the plan are started.  Right now  
> this is restricted to XmlAttributeBuilders and XmlReferenceBuilders  
> but the patch I'm working on for pluggable jacc will introduce the  
> possibility of using any namespace driven builder to interpret  
> pretty much arbitrary content.
>
> thanks
> david jencks
>
>>
>> --jason
>