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 Mon, 30 Oct 2006 22:14:14 GMT
On Oct 29, 2006, at 11:26 PM, David Jencks wrote:

> It's easy to tell you're not happy :-)

No... I'm not really happy.  I'm frustrated with Maven and all its  
little bugs and problems and I am really getting burt out on all of  
he other build muck... which appears to have no end in sight problems  
daily.


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

Sure, this is a problem with any m2 build... but the real issue that  
I was being sarcastic about was that we hid the configuration, the  
user editable configuration, of modules into CARs, which FORCE users  
to deal with building components to change trivial settings... and  
this has everything to do with Geronimo.


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

Um, CARs are also used at runtime are they not?  Will G embed Maven  
to process them?  If so, someone besides myself had better start  
learning Maven... because I am not gonna be very happy about  
supporting this... since I think that it is a bad idea, bad concept.


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

If this was pure build time, then yes... but its not.


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

Right, be he is still talking about a build time thing to build that  
xml-state and then zip it up into a jar, which I think is a huge  
mistake... don't zip up your config files, don't follow the crappy  
j2ee ear/war/ejb-jar code+config mess.


>> 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 am not proposing anything at this time... I never said I was.  I am  
still trying to understand why we have this super complex build to  
support these CAR things which IMO suck ass.


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

If you are not thrilled with XML configuration, then you probably are  
not looking at the problem from a user's standpoint, or a sysadmin,  
or really anyone who just wants to configure a G distro and now have  
to deal with building anything.

Geronimo is, IMO, fundamentally flawed in how it is configured.   
Because of this we can not even easily use Geronimo from a dist  
archive to run components for the gbuild.org hosts.  We need to be  
able to easily change the configuration that it comes with, strip off  
a few bits, change a few ports, etc.  This is a massive pain in the  
ass with Geronimo ASIS today... and this is primarily because of CAR  
files.

I hate J2EE archives, but really CAR files suck much much more... as  
I can't unzip a CAR, edit some XML, re-zip and then redeploy to get  
my changes in.  No... I have to go through this horrible build  
process which is a MASSIVE_PITA for us developers... and is basically  
not an option for anyone else.  Just go try to explain to your  
sysadmin that to change some configuration, that you have to go and  
rebuild the server.  That sounds like a great way to basically tell  
people to go use some other server which is easier to configure.


> 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 don't see any problems with the first idea of building a server  
from modules for a specific purpose...

But, the second, is a major problem... this is the crux of the  
configuration simplicity which I have been trying to express (over  
and over).

I do not see any reason why one could not simply do some build-time  
validation of xml config to ensure that it catches everything, but  
still deploy the xml, keep the xml in the file system, so its easy to  
grok and change.  Compiling this into serialized objects is a very,  
very, very bad idea.

Imagine, if Maven compiled its pom.xml into a pom.ser so that it was  
easier for Maven to be able to load and not have to worry about  
syntax errors... as someone might have changed the file... oh no.   
How much would you like that?  Maybe we can suggest that to them as a  
simplification of their modularization and plugin architecture.

Well, if you did not guess it... I am kidding of course.  Maven does  
not even use compiled ser objects for bits which users are not  
expected to edit, like mojo descriptors.  Its all xml, nice, easy to  
edit, usually easy to grok, xml.  No special tools required, have vi  
can edit, simple, simple, simple.


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

I am not against modules.  I am against compiled config.


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

Honestly... I prefer JBoss-style configuration, where the xml is fed  
into the deployment system and the application is assemblies/ 
configured on the spot from the xml input.

This is very sysadmin friendly.

But, no big surprise there as I was one of the people who helped  
implement that system.  I made many changes to that app server to  
make it easier for sysadmin's to use and operate.  And honestly... if  
someone asked me which server I would recommend that would be easy  
for a sysadmin to use... well, lets just say it would not be Geronimo.

--jason



Mime
View raw message