geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Maven2 vs. Geronimo Maven2 repository problems
Date Mon, 30 Oct 2006 07:26:07 GMT
It's easy to tell you're not happy :-)
On Oct 29, 2006, at 12:40 PM, Jason Dillon wrote:

> 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>

This seems to be a problem with all but the simplest m2 builds.  I  
don't think you can blame the non-working snapshot problems on  
geronimo rather than maven.
> 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

I've recommended for a while that we align geronimo and maven  
dependencies, but this would cause complete disruption of the svn  
tree and build order, and I haven't heard anyone say that they think  
its a good idea before 1.2 is out.  However, having them different  
causes major confusion in understanding the build and cars.
> 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.

Well, they're pretty much like maven plugins, they're used in the  
build.  Maybe there's some way to make them actually be maven plugins.
> 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.

Would configuring each deployer as a maven plugin solve this?
>  * * *
> 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...

Aaron did say he'd be happy with xml as the persistence format in a  
car file.  Right now a car file can include both configuration  and  
classes.  If you want to eliminate this possibility we're going to  
have to have to give maven some classloaders that can load specified  
parts of a j2ee artifact such as an ear with wars and rars inside.
> 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...

You aren't saying much definite about what you are proposing, so I  
can't discuss the merits or problems with what you want,  since I  
don't have a clue what it is, except that it involves xml.  I'm not  
thrilled with  xml configuration but I don't have any real problem  
with it.  I still do like the idea of car files.  I don't think that  
they need to be able to include classes, but that will require a lot  
of classloader magic to deal with actual j2ee artifacts in repos.

So, there are kind of 2 ideas behind geronimo modules, currently  
represented as car files.  One is the idea of building a server  
adapted to a specific purpose by assembling prebuilt modules someone  
else created.  The other is that, along the continuum from scripting  
languages to  compiled languages, we want geronimo modules to be as  
compiled as possible to find as many problems as possible during  
"compiling" (deployment) and to make the resulting code run (starting  
the modules) as fast as possible, and to reduce the amount of  
infrastructure needed at runtime, and possibly to provide a security  
and authentication structure for module installation auditing.

I think that we are getting reasonably near the goal of being able to  
build lots of servers from prebuilt modules.  Certainly the 4 servers  
we distribute are built out of nearly the same set of modules, and  
with the plugin stuff it's getting easier to add and remove modules  
from an existing server.  While there is more to do I think this is  
one of the successes of geronimo.

If you accept this idea of a modular server, then the question is  
what should the modules look like.  On the one hand you have jboss,  
which the last time I looked was heavily on the scripting end of the  
spectrum, starting from unprocessed xml descriptors and immediately  
constructing the runtime objects that will be the running server.  On  
the other hand you have traditional j2ee servers that e.g. generate  
code for ejbs and compile it into a jar.  The idea behind geronimo  
modules is to use deployers to turn whatever input is provided into  
persistable configuration information for services, and to save that  
configuration information in a standard format.  So, for instance, in  
a plain gbean plan you can have specialized xml for login  
configuration, tss and css corba security configuration beans, and  
persistence units.  They all get processed into GBeanDatas and get  
saved.  J2EE artifacts typically have 2 sets of xml, the spec dds and  
a geronimo plan: these get combined into GBeanDatas and saved, again  
in a standard format.  As a result, we can find a lot of problems  
while constructing a module before its installed anywhere, and we  
don't need any of the deployment infrastructure available when we  
need to actually start the module.

I'm very attached to the ideas of a modular server and separation of  
deploy-time and runtime activities.  I'm not particularly attached to  
the particular format of car files or the persisted configuration  
data, or the current limitation that all modules have to be in the  
same format.

I think that there are a lot of good ideas for the future here but  
that most of them will take a really lot of work and discussion to  
get right and working properly.  I also think that these ideas won't  
do anything to alleviate some of the problems you mentioned, such as  
the disconnect between maven's view of dependencies and geronimo's  
view of dependencies: if we could line them up then a lot of geronimo- 
specific configuration would be unnecessary or completely generated  
from poms.  I think starting with things we can do now,  
incrementally, without massive code disruption, will lead more  
quickly to a server our users are happy with.  I'm really reluctant  
to start on another massive refactoring of everything in geronimo:  
the last time we tried that (version independence) it took 6 months  
during which we got just about no new features.

david jencks

> --jason

View raw message