I think I resolved most of the "resolve to wrong version" problems
(basically #3 below), and I managed to start with framework and
deploy plugins until I got a working web console (jetty, and the old
non-modular console).
There are still a bunch of weirdnesses going on such as openejb
having NCDFE but this seems to me like a significant step towards
plugin usability.
There may be other problems such as I'm not sure the gbean configs
are getting copied into config.xml properly. I'll keep looking at
this stuff.
thanks
david jencks
On Sep 11, 2007, at 12:13 AM, David Jencks wrote:
I've now updated enough of the configs so we can see if we can
assemble them into a server. It would be great if some one else
could take a look at some of the remaining ones, list at the end of
this email. To get your own list of un-cleaned-up configs build g,
fire it up, and run search-plugins from the command line deployer:
the <no category> ones aren't done yet.
To provide a more reasonable sized testbed for assembling servers
out of plugins I also shrank geronimo-framework to the minimum
possible size: rmi-naming plus enough security to enable the
command line deployer to connect to it.
So, while some parts of plugin installation work, overall it
doesn't. I keep seeing plugin installation pull in the wrong
version of jars and cars and sometimes not find jars that are
present in the local maven repo.
Here are the problems I've noted so far, in order of discovery:
1. While reviewing config poms I saw some suspicious dependencies.
Axis and Axis2 depend on openejb which subverts any attempt to run
axis web services on a minimal server. The openejb-deployer
requires openejb to be running which subverts any attempt to deploy
offline while another server is running on the same machine (port
conflicts).
2. Figuring out which repository to look in doesn't work yet.
While what is specified in the geronimo-plugin.xml and geronimo-
plugins.xml does appear to be honored, using these isn't compatible
with developing and testing plugins, since while a plugin is being
worked on you want to use only your local repo but after its
published you don't (unless perhaps its is hooked up to some kind
of maven proxy) I wonder if having a "default" repo configured in
the plugin installer system would work, or perhaps merging the
repos at the end of geronimo-plugins.xml with those in each
geronimo-plugin.xml.
3. version resolution appears to have some serious problems. I
think pretty much all of the geronimo-plugin.xmls contain versions
for every jar (something I'm hoping to change) but I ran into a lot
of problems. First most of the artifacts got resolved to the 2.0.1
released artifacts which didn't work because the car files didn't
have valid geronimo-plugin.xmls in them. After I removed all my
2.0.1 artifacts things were slightly better until I got to
something that wouldn't resolve at all, xbean-reflect 3.2-
SNAPSHOT. The jar is in my local repo but for some reason it
wasn't found.
4. I am doubting more and more that the current "requires" and
"obsoletes" data are appropriate. For instance, most of the web
apps "require" jetty (or tomcat, pick your flavor). IMO this is
the wrong idea. If I want to install one of these web apps, it
should install the web server if it's not already present. What I
think is more appropriate would be if I'm trying to install a jetty
web app and tomcat is installed it should complain: if no other web
server is installed then it should install jetty for me.
5. Trying to extract information about what went wrong is really
hard and unpleasant.
6. With the CTS configs that happen to be on my machine, there are
93. This is a lot to wade through. We need a better way of
organizing them, at least on the command line. Perhaps providing a
list of categories to pick from, then the plugins from that
category, would be more manageable. Also a "deploy this from this
maven repo" command would be good: this might exist but I haven't
found it yet.
thanks
david jencks
<no category>
Geronimo Configs :: Welcome app Jetty
8 : (2.1-SNAPSHOT)
Geronimo Configs :: Unavailable Client Deployer
9 : (2.1-SNAPSHOT)
Geronimo Configs :: GBean Deployer
11: (2.1-SNAPSHOT)
Geronimo Configs :: Shared Library
12: (2.1-SNAPSHOT)
Geronimo Configs :: System Database
13: (2.1-SNAPSHOT)
Geronimo Configs :: Application Client Deployments
14: (2.1-SNAPSHOT)
Geronimo Configs :: J2EE Client transaction
15: (2.1-SNAPSHOT)
Geronimo Configs :: CLI Upgrade
16: (2.1-SNAPSHOT)
Geronimo Configs :: Unavailable EJB Deployer
17: (2.1-SNAPSHOT)
Geronimo Configs :: Plan Upgrade
20: (2.1-SNAPSHOT)
Geronimo Configs :: Shutdown
21: (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 JAR Configurer
23: (2.1-SNAPSHOT)
Geronimo Configs :: Welcome app Tomcat
24: (2.1-SNAPSHOT)
Geronimo Configs :: Corba J2EE Client
25: (2.1-SNAPSHOT)
Geronimo Configs :: Client System
26: (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 EAR Configurer
27: (2.1-SNAPSHOT)
Geronimo Configs :: GBean Deployer Boostrap version
28: (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 DeploymentFactory
29: (2.1-SNAPSHOT)
Geronimo Configs :: Servlet Examples for Tomcat
33: (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 CLI
34: (2.1-SNAPSHOT)
Geronimo Configs :: J2EE Client
35: (2.1-SNAPSHOT)
Geronimo Configs :: Unavailable Web Services Deployer
36: (2.1-SNAPSHOT)
Geronimo Configs :: UDDI Tomcat
37: (2.1-SNAPSHOT)
Geronimo Configs :: Servlet Examples for Jetty
38: (2.1-SNAPSHOT)
Geronimo Configs :: UDDI Jetty6
39: (2.1-SNAPSHOT)
Geronimo Configs :: J2EE Client Security
40: (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 RAR Configurer
43: (2.1-SNAPSHOT)
Geronimo Configs :: JSR88 WAR Configurer
45: (2.1-SNAPSHOT)