[
https://issues.apache.org/jira/browse/IGNITE-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15208138#comment-15208138
]
Vladimir Ozerov commented on IGNITE-2823:
-----------------------------------------
Igor, I assume that you moved to core only some classes for metadata handling.
Is that correct? We must ensure very clean separation of concerns here. Naming
scheme "common - utils" already looks pretty confusing to me. "common" is not
really "common" if it contains only JNI code, right?
I would do that as follows:
1) libcommon - contains various utilty methods. Concurrency primitives, work
with files, env variables, our generic classes (e.g. IgniteError, Guid), etc.
2) libjni (depends on libcommon) - contains JNI stuff. Class definitions, JVM
start code, JAVA_HOME resolution, actual methods, etc..
3) libbinary (depends on libcommon) - contains binary format, readers, writers,
macroses, etc. Possibly interfaces for metadata handling (not sure).
4) libcore - depends on libcommon, libjni, libbinary;
5) libodbc - depends on libcommon, libbinary.
Thoughts?
> CPP: Split libcommon in two libraries to get rid of libjvm dependency.
> ----------------------------------------------------------------------
>
> Key: IGNITE-2823
> URL: https://issues.apache.org/jira/browse/IGNITE-2823
> Project: Ignite
> Issue Type: Sub-task
> Components: odbc, platforms
> Affects Versions: 1.5.0.final
> Reporter: Igor Sapego
> Assignee: Igor Sapego
> Fix For: 1.6
>
>
> Currently libcommon depends on the libjvm but provides other utilities and
> macros which other libraries depend upon. So we need to link libcommon always
> when we use utils even if we don't use libjvm (e.g. in ODBC driver).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
