It's impossible to guess from the metadata available in that JAR that it's in fact jakarta.servlet:jakarta.servlet-api 4.0.3, for example. So the only way to fix this would be to introduce some format to provide a mapping between the Bundle-SymbolicName value from the META-INF and various metadata to help resolve the actual extension. For example, for this use case it could be something like:
which is not exactly since ${Specification-Version} is not the exact version of jakarta.servlet-api but just the major specification version but the alternative would be to have a different features line for each range of Tomcat version depending on the exact version of jakarta.servlet-api they embeded which would be quite a pain to maintain I'm afraid...
Thomas Mortagne on 12/Sep/24 16:18
It's impossible to guess from the metadata available in that JAR that it's in fact jakarta.servlet:jakarta.servlet-api 4.0.3, for example. So the only way to fix this would be to introduce some format to provide a mapping between the Bundle-SymbolicName value from the META-INF and various metadata to help resolve the actual extension. For example, for this use case it could be something like:
{noformat} org.apache.tomcat-servlet-api id=org.apache.tomcat:tomcat-websocket-api (for that one we could also relies on a default behavior which would try to deduce the right groupid and artifact id using a combination of the Bundle-SymbolicName, assuming the name of the file is the artifact id and following the rules indicated on https://cwiki.apache.org/confluence/display/SMX4/Creating+a+Bundle+Using+Maven#CreatingaBundleUsingMaven-Settingthebundle'ssymbolicname) version=${Bundle-Version} (should probably be the default behavior so I don't think we would indicate it most of the time) features=jakarta.servlet:jakarta.servlet-api/${Specification-Version} {noformat}
which is not exactly since ${Specification-Version} is not the exact version of jakarta.servlet-api but just the major specification version but the alternative would be to have a different features line for each range of Tomcat version depending on the exact version of jakarta.servlet-api they embeded which would be quite a pain to maintain I'm afraid...
Thomas Mortagne on 12/Sep/24 16:19
It's impossible to guess from the metadata available in that JAR that it's in fact jakarta.servlet:jakarta.servlet-api 4.0.3, for example. So the only way to fix this would be to introduce some format to provide a mapping between the Bundle-SymbolicName value from the META-INF and various metadata to help resolve the actual extension. For example, for this use case it could be something like:
{noformat} * *org.apache.tomcat-servlet-api* * * id=org.apache.tomcat:tomcat-websocket-api* (for that one we could also relies rely on a default behavior which would try to deduce the right groupid and artifact id using a combination of the Bundle-SymbolicName, assuming the name of the file is the artifact id and following the rules indicated on https://cwiki.apache.org/confluence/display/SMX4/Creating+a+Bundle+Using+Maven#CreatingaBundleUsingMaven-Settingthebundle'ssymbolicname) ** * version=${Bundle-Version}* (should probably be the default behavior, so I don't think we would indicate it most of the time) ** * features=jakarta.servlet:jakarta.servlet-api/${Specification-Version}* {noformat} which is not exactly since ${Specification-Version} is not the exact version of jakarta.servlet-api but just the major specification version but the alternative would be to have a different features line for each range of Tomcat version depending on the exact version of jakarta.servlet-api they embeded which would be quite a pain to maintain I'm afraid...
Thomas Mortagne on 12/Sep/24 16:20
It's impossible to guess from the metadata available in that JAR that it's in fact jakarta.servlet:jakarta.servlet-api 4.0.3, for example. So the only way to fix this would be to introduce some format to provide a mapping between the Bundle-SymbolicName value from the META-INF and various metadata to help resolve the actual extension. For example, for this use case it could be something like:
* *org.apache.tomcat-servlet-api* * * *id=org.apache.tomcat:tomcat-websocket-api* (for that one we could also rely on a default behavior which would try to deduce the right groupid and artifact id using a combination of the Bundle-SymbolicName, assuming the name of the file is the artifact id and following the rules indicated on https://cwiki.apache.org/confluence/display/SMX4/Creating+a+Bundle+Using+Maven#CreatingaBundleUsingMaven-Settingthebundle'ssymbolicname) ** *version=${Bundle-Version}* (should probably be the default behavior, so I don't think we would indicate it most of the time) ** *features=jakarta.servlet:jakarta.servlet-api/${Specification-Version}*
which is not exactly since ${Specification-Version} is not the exact version of jakarta.servlet-api but just the major specification version but the alternative would be to have a different features line for each range of Tomcat version depending on the exact version of jakarta.servlet-api they embeded which would be quite a pain to maintain I'm afraid...
Thomas Mortagne on 12/Sep/24 16:20
It's impossible to guess from the metadata available in that JAR that it's in fact jakarta.servlet:jakarta.servlet-api 4.0.3, for example. So the only way to fix this would be to introduce some format to provide a mapping between the Bundle-SymbolicName value from the META-INF and various metadata to help resolve the actual extension. For example, for this use case it could be something like: * *org.apache.tomcat-servlet-api* ** *id=org.apache.tomcat:tomcat-websocket-api* (for that one we could also rely on a default behavior which would try to deduce the right groupid and artifact id using a combination of the Bundle-SymbolicName and the file name, assuming/hoping the name of the file is the artifact id and following the rules indicated on [ https://cwiki.apache.org/confluence/display/SMX4/Creating+a+Bundle+Using+Maven#CreatingaBundleUsingMaven-Settingthebundle'ssymbolicname]) ** *version=${Bundle-Version}* (should probably be the default behavior, so I don't think we would indicate it most of the time) ** *features=jakarta.servlet:jakarta.servlet-api/${Specification-Version}*
which is not exactly since ${Specification-Version} is not the exact version of jakarta.servlet-api but just the major specification version but the alternative would be to have a different features line for each range of Tomcat version depending on the exact version of jakarta.servlet-api they embeded which would be quite a pain to maintain I'm afraid...
Thomas Mortagne on 12/Sep/24 16:22
It's impossible to guess from the metadata available in that JAR that it's in fact jakarta.servlet:jakarta.servlet-api 4.0.3, for example. So the only way to fix this would be to introduce some format to provide a mapping between the Bundle-SymbolicName value from the META-INF and various metadata to help resolve the actual extension. For example, for this use case it could be something like: * *org.apache.tomcat-servlet-api* ** *id=org.apache.tomcat:tomcat-websocket-api* (for that one we could also rely on a default behavior which would try to deduce the right groupid and artifact id using a combination of the Bundle-SymbolicName and the file name, assuming/hoping the name of the file is the artifact id and following the rules indicated on [https://cwiki.apache.org/confluence/display/SMX4/Creating+a+Bundle+Using+Maven#CreatingaBundleUsingMaven-Settingthebundle'ssymbolicname]) ** *version=${Bundle-Version}* (should probably be the default behavior, so I don't think we would indicate it most of the time) ** { *}features=jakarta.servlet:jakarta.servlet-api/${Specification-Version} ({*
}which is not exactly perfect since ${Specification-Version} is not the exact version of jakarta.servlet-api but just the major specification version but the. The alternative would be to have a different features line for each range of Tomcat version depending on the exact version of jakarta.servlet-api they embeded which but it would be quite a pain to maintain I'm afraid...)
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
