David Jencks wrote:
On Aug 19, 2008, at 2:48 PM, Joe Bohn wrote:
I've been looking into possible ways to get the Geronimo Sample
plugins created in such a way that they can be installed in multiple
Geronimo Server versions.
I had success doing this a few months back with the very, very simple
Geronimo Server Specific Repository plugin. It was possible to create
this plugin so that it could install on multiple server releases by
setting includeVersion to false in the car-maven-plugin configuration.
However, attempting to do the same for the samples isn't working as
smoothly. For example, if I add includeVersion false in the
jsp-examples-tomcat/jetty poms the geronimo-plugin.xml (and
geronimo-plugins.xml) are correctly generated with dependencies on
tomcat and jasper that omit the version (actually there is something
else wrong where it shows 1 dependency on jasper but 2 on tomcat -
none with versions ... but that's a different problem). However, when
I attempt in install the plugin a Geronimo 2.1.1 or 2.2-SNAPSHOT
server image the gbean fails to start because of a missing dependency
on org.apache.geronimo.configs/tomcat6/2.1.2/car. I can't figure out
where it is picking up this versioned dependency. Any ideas?
probably the default environment in tomcat-deployer
The only difference I notice between the server-repo plugin where this
works and the sample where it doesn't is that the samples utilize the
deploymentConfigs in the car-maven-plugin configuration. At the
moment these entries must include a geronimo version or we get a NPE
during the build (I was thinking of seeing it we could default a
version if none is provided for the deployer but I'm not sure that is
the issue anyway).
I don't think that would work. Maven needs to know what you want here.
Is it possible that some dependency is getting pulled in because of
the deployer and perhaps persisted somewhere hidden (like in the
config.ser file)? This is really driving me nuts.
I think more and more that all or most dependencies should be specified
with versions and we should use artifact-aliases for when we want to
change them.
What happens if you include all versions in the samples and map all
these versions to whatever is present in the server in
artifact-aliases.properties? Might not be trivially easy to set up, but
does it work?
Thanks for the response David. The aliases did work a while back when I
created a set that included all of the configs that we in the Tomcat
assembly. I didn't expand it to include the jetty delta but that should
work as well. I was hoping to come up with a more simple solution that
would work for all 2.x releases without additional install requirements.
I guess if we can't enhance the car-maven-plugin to assume it's own
version if one isn't specified then I'll have to resort to the aliases
again.
