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
