You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2006/06/28 00:25:28 UTC
What is the point of the CAR file?
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?
--jason
Re: What is the point of the CAR file?
Posted by Dain Sundstrom <da...@iq80.com>.
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?
+1
-dain
Re: What is the point of the CAR file?
Posted by 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
>
Re: What is the point of the CAR file?
Posted by Jason Dillon <ja...@planet57.com>.
To be clear...er
I am still not convinced that we need CAR files to make G work... but
we can look into this more later once we have a functional build and
most likely 1.2+ out the door.
We'll see... maybe i will see the light and hop on the CAR
bandwagon... or maybe not. I commented on this to get a better
understanding for while it was needed to make G operate (and still
pending some concrete details). My gut tells me that there is a
simpler way to get to the same goal... and we should examine if that
is possible... BUT, I'm not suggesting in any way that we block
progress (of the m2 build or anything) because of it.
--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
>
Re: What is the point of the CAR file?
Posted by Jason Dillon <ja...@planet57.com>.
>> 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.
Why can't that basic format be the plan.xml file?
> Starting with the plan.xml at runtime will require making sure
> somehow that any builders needed to interpret the plan are started.
Why is this a bad thing? I would personally rather do this, than
have a build-time process generate a serialized object and then use
that as the input for the server. I'd much, much rather see the XML
file go to the server and then have it perform all required processing.
* * *
It seems to me that the CAR file and the required maven plugin to
generate it is one of the biggest problems that we are going to run
into when moving to m2. I don't believe that we want to have our
build process be dependent on artifacts of the same build.
IMO, removing of CAR files would be a significant simplification from
build and deployment aspects.
Having to have builders loaded/running in the server does not seem
like a major problem to me (or even a minor problem).
But, I do see that the chicken-egg plugin required to generate CAR
files is a major problem.
--jason
Re: What is the point of the CAR file?
Posted by David Jencks <da...@yahoo.com>.
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