Wow, this all looks great! Now that the underlying stuff is more
stabilized and functionally complete I can help bring the admin
console up to date. I think the CLI might also need some touching up.
One question I have is should we keep the reference to:
http://www.geronimoplugins.com/repository/geronimo-1.1/
in the default source-repositories listed in configs/pom.xml? I
don't know if there are any plans to provide a repository of
geronimo's 2.x plugin artifacts or their dependencies from that
location. If there plans for that then we should leave the reference
in place (the more repos the better, I say) but may need to update
the geronimo version number in the URL.
I'm also thinking we should add a reference to:
http://geronimo.apache.org/plugins/geronimo-2.1/
in the source-repo list in configs/pom.xml and update that URL as we
increment the server version and create new repos. Or maybe we
should start using a single repo and URL for all versions of geronimo
since GERONIMO-3330 has been implemented. Now that the catalog
schema provides this flexibility we can decide how to use it - one
repo and catalog for supporting multiple versions of geronimo or a
repo for each version. We have discussed some pros and cons of both
options. I'm pretty sure that plugin repos like the one at
geronimo.liferay.com will want to use a single repo since its easier
to update and maintain the catalog. But for our server plugins we
may want to have a repo per version since the car maven plugin can
automagically create the catalog (very cool feature).
Best wishes,
Paul
On Sep 7, 2007, at 8:00 PM, David Jencks wrote:
I think the plugin installer stuff might be pretty much
functionally complete.
In the plugin-config.xml you can specify bits of config.xml,
artifact_aliases.properties, and config-substitutions.properties.
I think this might be enough installation stuff to build a server.
The car-maven-plugin now:
- constructs the geronimo-plugin.xml and processes the plan.xml.
- dependencies can be from the maven dependencies with or without
versions (all compile and runtime dependencies in the current pom
are included)
- or dependencies can be explicitly specified in the c-m-p
configuration.
- bits like name, descriptions, licesnes, url, moduleId are derived
from the pom with normal maven inheritance.
- everything else in the geronimo-plugin.xml is derived from a
template in the pom. There are 2 of these: a commonInstance you
can put in a parent pom that provides defaults, and an instance
that you put in the pom itself. Collections in the instance
replace rather than add to stuff specified in the commonInstance.
Both of these follow the plugin-artifactType but you can leave out
xml namespaces. Don't have more than one of instance or
commonInstance in any sequence of pom ancestors: maven
interpolation doesn't work on these and will break whatever you are
trying to do.
- when you build a car, the plugin will update ~/.m2/repository/
geronimo-plugins.xml with the new geronimo-plugin.xml information.
- to construct an entirely new geronimo-plugins.xml in your local
maven repo run
mvn org.apache.geronimo.plugins:car-maven-plugin:create-pluginlist
I've set the default repo list to include this in the local maven
repo for the jetty javaee assembly on osx. I'd like it if someone
with a windows setup could test if it works on windows as well.
Then we can update the tomcat configuration. To test, update and
build trunk, start the jetty javaee server, and on a separate
console window run java -jar bin/deployer.jar search-plugins
You should see the local maven repo listed and if you select it
you should see all the cars in the server listed.
The stuff in the admin console works a little bit but still needs
some TLC from someone with a clue about UIs.
thanks
david jencks
On Sep 3, 2007, at 10:55 AM, David Jencks wrote:
I've committed what I have so far:
- use new plugin schema
- generate geronimo-plugin.xml files for each car from pom.xml
- generate plan environment section from explicitly listed car-
maven-plugin configuration instead of from maven dependencies. We
check that each dependency listed in the maven plugin config is
actually present in the maven dependencies section.
- moved car plans to src/main/plan/plan.xml
- include plan in the car for reference.
Problems/left to do:
- I haven't converted many of the car poms to actually generate
the correct geronimo-plugin.xml or the correct plan, so most plans
have the previously generated dependencies in them. There are a
lot (nearly 100) so if anyone wants to help me update the poms
that would be great. I did do a few of the cars with existing
geronimo-plugin.xmls.
- the xml configuration format in pom.xml is adapted for maven,
not for jaxb. It would be great if we could figure out how to
make the configuration in pom.xml look more like geronimo-
plugins.xml or the environment element.
- The cli search-plugins and console plugin installer work, but
only sort of. For instance they don't show you which plugins are
installed or would have problems due to prerequisite or obsoletes
problems. I'm hoping someone less clueless about uis can help
with this part.
- in order to get this to work quickly I added jaxb dependencies
to lib. I think this is really bad and hope we can figure out how
to remove them again.
Let me know if I've broken other stuff :-)
thanks
david jencks
On Aug 31, 2007, at 10:28 AM, David Jencks wrote:
So I have the code compiling but now all the geronimo-plugin.xml
files are in the old format... :-(
I'm going to look into generating them in the car-maven-plugin
along with making a car-maven-plugin configuration that includes
the dependencies more directly so we don't spend hours trying to
generate them from the maven dependencies.
thanks
david jencks
suffering from feature creep...
On Aug 29, 2007, at 12:26 PM, David Jencks wrote:
I'm going to take a couple days to see if I can get the plugin
installer in better shape.
My goals are:
- new schema as in GERONIMO-3330
- jaxb based
- easier to use the local maven repo as a plugin repo. This
might be done by having a "scan repo and generate geronimo-
plugins.xml from all the plugins we find" function.
- let plugin xml contain more global bits. Right now it can
contain config.xml bits, it should be able to modify other
config.xml type files (offline deployer, etc) and
artifact_aliases and config-substitutions properties files. The
changes to the properties files need to be live so e.g. when the
plugin is started the new entries get used.
thanks
david jencks