[ 
https://issues.apache.org/jira/browse/DERBY-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071704#comment-16071704
 ] 

Bryan Pendleton commented on DERBY-6944:
----------------------------------------

Restating what I think you're proposing: the classpath field in the jar 
manifest could list each named jar twice:
1) First with a long jar file name, including the specific version number that 
matches this jar's version
2) Then with a shorter jar file name (the current jar file name) which has no 
version number

Then the normal classpath-searching behaviors would find the jar file by 
version first, if it existed, and if it didn't, would look for the jar file 
with no version string in its name.

It seems like a clever idea to me.

But, historically, Derby has suffered from very subtle bugs when it becomes 
possible to get two different versions of the Derby jar files into the same 
classpath.

Would we be introducing a new vector of such misconfiguration bugs?

> tomcat, maven, derby jar file manifest, jar naming
> --------------------------------------------------
>
>                 Key: DERBY-6944
>                 URL: https://issues.apache.org/jira/browse/DERBY-6944
>             Project: Derby
>          Issue Type: Improvement
>          Components: Localization
>    Affects Versions: 10.5.3.0, 10.13.1.1
>            Reporter: Martin Sillence
>            Priority: Minor
>
> The main derby jar file has a manifest with a classpath entry e.g.
>  Class-Path: derbyLocale_cs.jar derbyLocale_de_DE.jar...
> When using maven repository it downloads the files with the version numbers 
> in it:
> derbyLocale_cs-10.5.3.0_1.jar
> if deployed on a recent version of tomcat the manifest it automatically 
> interrogated and tomcat attempts to load the jar files as named. This fails 
> as the names do not match.
> Also the additional files are not specified as dependencies in the derby 
> pom.xml file so they are not automatically retrieved.
> Please would you consider adding in the dependencies to the published files 
> and putting in the version in the names in the manifest when publishing to 
> maven?
> Workarounds:
> fetch maven dependencies with "-Dmdep.stripVersion=true"
> Turn off auto loading of manifest classpath for all files
> add:  <JarScanner scanManifest="false"/>
> to tomcats context.xml



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to