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
