[
https://issues.apache.org/jira/browse/COMPRESS-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035516#comment-16035516
]
ASF GitHub Bot commented on COMPRESS-399:
-----------------------------------------
Github user joehni commented on the issue:
https://github.com/apache/commons-compress/pull/26
Why are those packageinfo files in src/main/java instead of
src/main/resources as it is common in Maven builds? Now you have to configure
explicitly these files as resources. On top of it, I don't like the idea of
modifying these files for each release manually. I'd look for a solution that
generates these files automatically into target/generated-resources. Such a
plugin should not be difficult.
> OSGI package versions are overly pessimistic, except when they're overly
> optimisic
> -----------------------------------------------------------------------------------
>
> Key: COMPRESS-399
> URL: https://issues.apache.org/jira/browse/COMPRESS-399
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.14
> Reporter: Simon Spero
> Priority: Minor
> Fix For: 1.15
>
> Original Estimate: 0h
> Remaining Estimate: 0h
>
> The OSGI versions in the current distributions are not being correctly
> generated. OSGI relies on package version numbers following semantic version
> properly for correct resolution.
> Current version numbers have been generated from the maven version. This has
> lead to new minor version increases for packages that have no API changed; it
> has also concealed major (breaking) changes to several packages since 1.0.
> I have created two branches that address the issue.
> Both add the bundle:baseline goal to the verify phase of the build.
> The also both have packageinfo files added to every package, containing the
> package version. These are picked up by the bundle manifest generator, and
> are used if no explicit version is given in the "Export-Package" command.
> Both branches bump the major version number for packages with any minor
> changes to 2.0.0. This makes the bundle correct, but does not fix improper
> import declarations made by users of earlier bundles.
> One branch uses the version number from the oldest version that has no
> changes when compared to HEAD, and which has not had any breaking changes
> since 1.0.0. This will fail the build because version numbers should be
> increasing, and may cause issues if an importing bundle uses a range that
> requires an identical, but higher numbered version of the package
> The other branch uses version 1.14.0 for all packages with no major changes.
> A third alternative, which I didn't add, is to just set all packages be
> version 1.14.0, and just bump major versions when required going forward. The
> bulk of the major changes happened a good few versions back, so it's not as
> bad as it could be.
> If you have a preferred option, I can create a pull request on Github
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
