Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 11 Jul 2016 08:20:11 +0000 (UTC)
From: "Dapeng Sun (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12986615.1467643734000.74764.1468225211015@Atlassian.JIRA>
In-Reply-To: <JIRA.12986615.1467643734000@Atlassian.JIRA>
References: <JIRA.12986615.1467643734000@Atlassian.JIRA> <JIRA.12986615.1467643734959@arcas>
Subject: [jira] [Updated] (CRYPTO-104) Native code should provide
 getVersion() methods
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 11 Jul 2016 08:20:12 -0000


     [ https://issues.apache.org/jira/browse/CRYPTO-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dapeng Sun updated CRYPTO-104:
------------------------------
    Assignee: Sebb

> Native code should provide getVersion() methods
> -----------------------------------------------
>
>                 Key: CRYPTO-104
>                 URL: https://issues.apache.org/jira/browse/CRYPTO-104
>             Project: Commons Crypto
>          Issue Type: New Feature
>            Reporter: Sebb
>            Assignee: Sebb
>             Fix For: 1.0.0
>
>
> It would be useful to have getVersion() methods for the native code.
> These should be able to return:
> - the VERSION used to create the library (i.e. project.version)
> - the NAME used to create the library (i.e. project.name)
> - the BUILD_DATE might also be useful
> - the OpenSSL version string
> - the SSLeay_version details
> Although the Java jar and the native code are generally built together, they are distributed as separate files, so it's useful to be able to identify their versions independently at run-time.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)