geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: Maven2 vs. Geronimo Maven2 repository problems
Date Sun, 29 Oct 2006 20:40:33 GMT
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


Mime
View raw message