geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: versioned dependencies are driving me nuts
Date Tue, 19 Aug 2008 22:53:42 GMT
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.


Mime
View raw message