[jira] [Comment Edited] (CSV-314) Missing OSGi Import-Package versions in Manifest can make commons-csv unusable in OSGi environments

["Gary D. Gregory (Jira)" <ji...@apache.org>]

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

Gary D. Gregory edited comment on CSV-314 at 11/18/24 4:47 PM:
---------------------------------------------------------------

Hi [~Adhip]

Feel free to create a PR and I'll be happy to review it.




was (Author: garydgregory):
Hi [~Adhip]

Feel free to create a PR and I'll be happy to review it



> Missing OSGi Import-Package versions in Manifest can make commons-csv unusable in OSGi environments
> ---------------------------------------------------------------------------------------------------
>
>                 Key: CSV-314
>                 URL: https://issues.apache.org/jira/browse/CSV-314
>             Project: Commons CSV
>          Issue Type: Bug
>    Affects Versions: 1.11.0
>            Reporter: K P
>            Priority: Major
>
> Since commons-csv 1.11.0, this library depends on *commons-codec* and on {*}commons-io{*}. Up to version 1.10.0, there were no (compile) dependencies.
> Since 1.11.0, the MANIFEST.MF contains *OSGi Import-Package headers* in the MANIFEST.MF, to import the required packages when running in an OSGi environment.
> However, those Import-Package headers don't define a (minimal) version of those commons-codec or commons-io packages.
> As a consequence, depending on the exact OSGi environment and bundle loading order, someone may be unlucky and commons-csv may happily resolve against an _older_ commons-codec or commons-io, even though some of its code requires more recent commons-codec or commons-io API. This will result in runtime errors, later at runtime, whenever commons-csv tries to call such "recent" commons-io or commons-codec code.
> This is similar to this commons-text issue: TEXT-233
> The Apache maven-bundle-plugin calculates and generates the following Import-Package headers (commons-csv 1.12.0) :
> {code:java}
> Import-Package: org.apache.commons.codec.binary,org.apache.commons.io,or
>  g.apache.commons.io.function,org.apache.commons.io.input,org.apache.com
>  mons.io.output {code}
> Unfortunately, the maven-bundle-plugin currently doesn't add an explicit (minimal) version number directive to these header. So while loading commons-csv, OSGi may resolve this against older commons-codec or commons-io jars (if it sees those older versions first, for whatever reason).
> However, on a few places, commons-csv relies on code that only exists since specific versions of those dependencies. E.g. the CSVParser ctor refers UnsynchronizedBufferedReader, which only exists since commons-io 2.17.0.
> We had a case where in the OSGi environment commons-csv was resolved against an older commons-io (2.15.1 or 2.11.0 or so), which then resulted in an exception the 1st time commons-csv tried to parse a csv :
> {code:java}
> Caused by: java.lang.NoClassDefFoundError: org/apache/commons/io/input/UnsynchronizedBufferedReader
>     at org.apache.commons.csv.CSVParser.<init>(CSVParser.java:444) ~[?:?]
>     at org.apache.commons.csv.CSVParser.<init>(CSVParser.java:412) ~[?:?]
>     at org.apache.commons.csv.CSVParser.parse(CSVParser.java:311) ~[?:?] {code}
> Similar issues may pop up elsewhere where commons-io or commons-codec gets called.
> I suppose that the solution would be similar to the solution of the commons-text issue:
> i.e. in the pom.xml :
>  * define properties for the commons-codec and commons-io version
>  * define a property {_}commons.osgi.import{_},
> where all the required import-packages need to be specified explicitly, with the required version directive.
> (This property is then picked up by the maven-bundle-plugin in the commons-parent pom)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)