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.
thanks
david jencks
--jason
