Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
From: sesuncedu <git@git.apache.org>
To: dev@commons.apache.org
Reply-To: dev@commons.apache.org
References: <git-pr-26-commons-compress@git.apache.org>
In-Reply-To: <git-pr-26-commons-compress@git.apache.org>
Subject: [GitHub] commons-compress issue #26: COMPRESS-399 OSGI package versions are overly pe...
Content-Type: text/plain
Message-Id: <20170602203303.9DBC7DFBC6@git1-us-west.apache.org>
Date: Fri,  2 Jun 2017 20:33:03 +0000 (UTC)
archived-at: Fri, 02 Jun 2017 20:33:05 -0000

Github user sesuncedu commented on the issue:

    https://github.com/apache/commons-compress/pull/26
  
    It's difficult to generalize, since the packageinfo files have to be put in
    with the source code. Since a  export header parameter with an explicit
    version overrides packageinfo and annotations, defaults can be problematic.
    
    Adding the resource copy and rat excludes is good, as is keeping up with
    the felix bundle versions.
    
    Adding a bundle:baseline goal to the parent verify phase is a really,
    really good idea if bundle headers are going to be generated. Package
    versions MUST  follow semver (bundle versions also, but to a lesser
    extent).
    
    
    Maven versions theoretically ought to too, but dependencies are usually
    point versions not ranges.
    
    (Of course, there's always guava, where version is a major release, except
    for bug fixes, which are minor.)
    
    The real  work is getting the api and implementation(s) properly
    modularized so that the api isn't always affected by implementation
    changes.  At least jigsaw has gotten people to start thinking about
    modules. Not always sensibly....
    
    On Jun 2, 2017 2:38 PM, "Gary Gregory" <notifications@github.com> wrote:
    
    > Hi,
    >
    > Should any of this work also apply to commons-parent?
    >
    > Gary
    >
    > —
    > You are receiving this because you authored the thread.
    > Reply to this email directly, view it on GitHub
    > <https://github.com/apache/commons-compress/pull/26#issuecomment-305876373>,
    > or mute the thread
    > <https://github.com/notifications/unsubscribe-auth/AAZIG7Xv74lnd98TXW3kzw9huxG2US7Rks5sAFaZgaJpZM4NukX5>
    > .
    >


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org