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
