On Oct 29, 2006, at 5:11 AM, Aaron Mulder wrote:
Just for the record, I like having a "post-processed" module format.
I wouldn't mind if it had XML data instead of serialized objects, but
I am not really in favor of throwing it away and making a standard
("pre-processed") J2EE JAR+DD+deployment plan into our official module
format. So I'd rather find ways to make the CAR builds work right.
:)
<sarcasm>
Ya, I really love having config files tucked away in little objects
zipped up in jar files. Ya, and then when I want to change some of
that config... I really love how I have to rebuild the entire
server... which is so easy... oh do I have the latest dependencies in
my local repo, oh... it will only take a few hours to download, and
pray my local repo does not have bunk metadata... and oh wait are all
those deps on the snapshot repo... didn't some apache stuff crash
again??!?
</sarcasm>
CAR files are not simple from a users perspective, or from an
application builders either. The only guy who things these are
simple is the little gremlin that needs to load CARs into the
server... which is great, we have pushed all of the complexity out of
the server and into the build process, which I can certainly tell you
had not simplified my life, as I have been chasing down CAR problems
for weeks and weeks now.
How do CAR files make anyones job easier (except for that little
gremlin that is)? How do CAR files simplify the configuration of a
server? How do CAR files simplify building a custom application on
top of Geronimo? How do they make building plugins any easier?!
From what I have gathered so far, from the mailing list, and other
complaints about car plugin failures and other mvn related muck... is
that CAR files only worsen the situation, making G more complicated
to configure and comprehend.
Months ago, when I came back to help on Geronimo... It took me weeks
to discover where the configuration was for the ActiveMQ broker...
and I just wanted to change one little attribute. And back then the
m1 build would almost never make it 10 modules before it was puking
on something, so I could not ever rebuild the server to change that
one attribute.... and soon I gave up.
The complexity that is comes along with CARs, whether it be a users
frustration about finding and changing configuration, or a developers
frustration about why a CAR module build is failing... and needing to
track down David Jencks, who seems like one of the only folks able to
comprehend what's going on, or maybe your frustration when trying to
get a plugin CAR build to include the correct server deps...
K.I.S.S and ditch the CARs.
But anyway, isn't there some way to get Maven to tell you why it's
chosen to download some particular module? It gives you that nice
little "dependency trace" when it fails to find something, but I would
hope there's some debug mode where it shows that for everything...
No Aaron, this is not Maven anymore... 90% of CAR'ing is done from
the Kernel. Only a very thin Maven veneer is used to setup the
Kernel components and feed it some data. After that it is the little
gremlins at work that do the rest... and they do not know anything
about Maven, or Mavens dependency tree, or really even how to barf up
intelligent error messages, or provide more debug intel with -X
For example... CAR builds depend on artifacts which are not directly
listed in the Maven projects pom.xml... the deployers, which the
Kernel will do something with... and those deps need to be fully
transitively resolved in the Maven repo before that will function
correctly. None of those deps will show up in any Maven trace, as
Maven knows absolutely nothing about them.
And if you add the deps for the deployers to your module... then the
CAR gremlins start to do more muck with them, which often causes a
CAR build to fail, even if you set the scope to provided... or was it
test? I can't recall since we have bastardized the maven scope
mechanism to add custom semantics to CAR dependencies.
* * *
I have heard from a few peeps, like you, that you don't want to get
rid of CAR files... but I have yet to hear of any substantial reasons
why they should stay. I have also heard from many other peeps about
how they would like to see CAR files go away and be replaced by
simple XML... which is what I am a major supporter of. I have on
many occasions ranted about the issues I have with CAR files, the
added complexity, blah, blah, blah...
Where are the arguments for those few who are in favor of the CAR?
Perhaps we should also take a poll from our users... and see if they
like having config compiled up into objects and zipped up and tossed
in the repo... or if they would like a set of plain XML files? I
wonder which they will choose...
--jason
