Re: Ignite Maven project version number
Hi All,
We used this approach 1.5 years before, but had some problems with
assemblying and deploying.
I can't remember what type of problem it was, possible they are already
solved.
I think we should refactor master branch as Igor described and check it
works.
Igor,
could you please implement it, check assemblying works (Ignite Fabric Maven
Build Instructions section at DEVNOTES.txt) and create pullrequest?
On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda wrote:
> Anton, would you mind providing your thoughts on this.
>
> —
> Denis
>
> > On Aug 12, 2016, at 6:02 PM, Igor Rudyak wrote:
> >
> > Guys,
> >
> > Found that each time after publishing new Ignite release and switching to
> > development of next version, version numbers are copy-pasted in all
> module
> > POMs. Isn't it better just to define project version variable in one
> > place(and change it in one place) to reuse it in module POMs?
> >
> > For example, variable like ${app.version} could be defined in parent POM
> > and all module POMs can just reuse it like this:
> >
> > *my-module*
> > *${app.version}*
> >
> > Igor
>
>
[jira] [Created] (IGNITE-3692) IGFS: Hangs in local secondary file system tests.
Vladimir Ozerov created IGNITE-3692: --- Summary: IGFS: Hangs in local secondary file system tests. Key: IGNITE-3692 URL: https://issues.apache.org/jira/browse/IGNITE-3692 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.7 Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 1.8 Caused by bad tests design. Need to rework it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3693) IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testFormat fails.
Vladimir Ozerov created IGNITE-3693:
---
Summary: IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testFormat
fails.
Key: IGNITE-3693
URL: https://issues.apache.org/jira/browse/IGNITE-3693
Project: Ignite
Issue Type: Bug
Components: IGFS
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Taras Ledkov
Fix For: 1.8
Sample failure:
http://149.202.210.143:8111/viewLog.html?buildId=299667&tab=buildResultsDiv&buildTypeId=IgniteTests_IgniteGgfs
Stack trace:
{code}
java.lang.AssertionError: null
at
org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.testFormat(IgfsAbstractSelfTest.java:1079)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
at java.lang.Thread.run(Thread.java:745)
--- Stdout: ---
[09:18:08,853][INFO ][main][root] >>> Starting test:
IgfsLocalSecondaryFileSystemDualAsyncSelfTest#testFormat <<<
[09:18:08,873][INFO ][main][root] >>> Stopping test:
IgfsLocalSecondaryFileSystemDualAsyncSelfTest#testFormat in 19 ms <<<
--- Stderr: ---
[09:18:08,872][ERROR][main][root] Test failed.
java.lang.AssertionError
at
org.apache.ignite.internal.processors.igfs.IgfsAbstractSelfTest.testFormat(IgfsAbstractSelfTest.java:1079)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3694) IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testAppendConsistencyMultithreaded hangs.
Vladimir Ozerov created IGNITE-3694: --- Summary: IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testAppendConsistencyMultithreaded hangs. Key: IGNITE-3694 URL: https://issues.apache.org/jira/browse/IGNITE-3694 Project: Ignite Issue Type: Bug Components: IGFS Affects Versions: 1.7 Reporter: Vladimir Ozerov Assignee: Taras Ledkov Fix For: 1.8 Root cause is unknown. Need to investigate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] ignite pull request #960: IGNITE-3693 IgfsLocalSecondaryFileSystemDualAsyncS...
GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/960 IGNITE-3693 IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testFormat fails. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3693 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/960.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #960 commit 1d0cbb45cd61c5c8e6ec926d7e629eb94111b32f Author: vd-pyatkov Date: 2016-08-11T05:43:50Z IGNITE-3618: Client can not load data after server restarts. This closes #941. commit 1139a9f76b5d37073261d729a15b1fbec674d48d Author: vozerov-gridgain Date: 2016-08-11T05:47:48Z Added missing license. commit 0b4ffdbcce63e5ce53572f71af967cff300d5670 Author: vozerov-gridgain Date: 2016-08-14T15:18:40Z IGNITE-2852: Fixed TreeMap and TreeSet serialization. commit 89bce0fc5cb3dba56626c7088e607d0b25c3353c Author: vozerov-gridgain Date: 2016-06-30T10:14:16Z IGNITE-3021: IGFS: Fixed failiing IgfsStreamsSelfTest.testCreateFileColocated() test. Failure as caused by misconfiguration. commit 78aa065b4c7b05381b1fa31159b74969ec4a2bfe Author: vozerov-gridgain Date: 2016-07-21T10:15:35Z IGNITE-826: Removed HadoopHashMapSelfTest.testAllocation() as it tested nothing. commit f87ca482420fc1e6ffcb000a227717142d24e270 Author: vozerov-gridgain Date: 2016-07-21T10:15:41Z IGNITE-826: Removed HadoopHashMapSelfTest.testAllocation() as it tested nothing. commit 9ddf9d846f52a4e8fc433643409993884c70ce37 Author: vozerov-gridgain Date: 2016-07-21T13:00:45Z IGNITE-466: IGFS: Added "IgfsMode mode(IgfsPath)" method. commit dc81069ba9ebb88bc11cf6917e8733cc1f6de2fb Author: Ivan Veselovskiy Date: 2016-08-02T08:11:24Z IGNITE-3343: IGFS: Secondary file system is not queried for statuses during MKDIRS and CREATE operations. This closes #896. commit ae54e36f27719f46d1d276f62a977c3f8d053b44 Author: tledkov-gridgain Date: 2016-08-04T14:04:41Z IGNITE-3331 IGFS: Route client tasks to primary node when metadata co-location is enabled. This closes #921. commit 970137b1db7dc6c5e546581e22e428ae15c86513 Author: vozerov-gridgain Date: 2016-08-05T12:05:32Z IGNITE-3631: IGFS: Now metadata co-location is used for PARTITIONED cache as well. commit 4d876a7560060c892908da447178e97bfe12ca9c Author: vozerov-gridgain Date: 2016-08-05T12:05:43Z IGNITE-3631: IGFS: Now metadata co-location is used for PARTITIONED cache as well. commit f5a040a01280c654df1fc4789cc39ff1ac2d32a4 Author: tledkov-gridgain Date: 2016-08-09T07:01:56Z IGNITE-3332: IGFS: Optimized file unlock routine with help of a client callable. This closes #916. commit 5cf3bea32a25ccc78641f083aa7f1ac81b4187ba Author: vozerov-gridgain Date: 2016-08-15T10:40:41Z IGNITE-1926: IGFS: Implemented local secondary file system. commit 278633eced6d8039b5be4a18eefe6c65650aba4f Author: Yakov Zhdanov Date: 2016-08-15T11:27:22Z IGNITE-3688: Fixed visiblity issue in GridCacheIoManager.idxClsHandlers. commit 09a3922d57f9a4c8fbe6c1056f3ea128869c250e Author: vozerov-gridgain Date: 2016-08-16T09:52:09Z IGNITE-3692: IGFS: Test fixes. commit e70259070109f1bb068651a48e39fe8433c61a3d Author: tledkov-gridgain Date: 2016-08-16T12:03:54Z IGNITE-3693 IgfsLocalSecondaryFileSystemDualAsyncSelfTest.testFormat fails --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (IGNITE-3695) CPP: Consider changing naming style to match boost/standard library.
Igor Sapego created IGNITE-3695:
---
Summary: CPP: Consider changing naming style to match
boost/standard library.
Key: IGNITE-3695
URL: https://issues.apache.org/jira/browse/IGNITE-3695
Project: Ignite
Issue Type: Task
Components: platforms
Affects Versions: 1.5.0.final
Reporter: Igor Sapego
Fix For: 2.0
It may be reasonable to change C++ naming style to match {{std}}/{{boost}}.
This can be helpful when defining classes that are supposed to be usable with
standard library. Also, it may be useful when using modern C++ features like
[range-based for loop|http://en.cppreference.com/w/cpp/language/range-for].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3696) .NET: Java type mapping does not work with nullable types
Pavel Tupitsyn created IGNITE-3696: -- Summary: .NET: Java type mapping does not work with nullable types Key: IGNITE-3696 URL: https://issues.apache.org/jira/browse/IGNITE-3696 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 1.6 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 1.8 See JavaTypes class. We should probably map nullables there too. Java has everything nullable by default, need to explain to the users that anything can be null underneath. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3697) .NET: Improve test coverage: reach 100% methods coverage
Pavel Tupitsyn created IGNITE-3697: -- Summary: .NET: Improve test coverage: reach 100% methods coverage Key: IGNITE-3697 URL: https://issues.apache.org/jira/browse/IGNITE-3697 Project: Ignite Issue Type: Improvement Components: platforms Affects Versions: 1.8 Reporter: Pavel Tupitsyn Fix For: 1.8 Previous step achieved 100% class coverage, next step is to cover 100% methods. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] ignite pull request #953: IGNITE-3368 .NET: Improve test coverage
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/953 --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Ignite Maven project version number
Ok, I'll create a ticket and implement it.
Igor
On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov wrote:
> Hi All,
>
> We used this approach 1.5 years before, but had some problems with
> assemblying and deploying.
> I can't remember what type of problem it was, possible they are already
> solved.
>
> I think we should refactor master branch as Igor described and check it
> works.
>
> Igor,
> could you please implement it, check assemblying works (Ignite Fabric Maven
> Build Instructions section at DEVNOTES.txt) and create pullrequest?
>
>
> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda wrote:
>
> > Anton, would you mind providing your thoughts on this.
> >
> > —
> > Denis
> >
> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak wrote:
> > >
> > > Guys,
> > >
> > > Found that each time after publishing new Ignite release and switching
> to
> > > development of next version, version numbers are copy-pasted in all
> > module
> > > POMs. Isn't it better just to define project version variable in one
> > > place(and change it in one place) to reuse it in module POMs?
> > >
> > > For example, variable like ${app.version} could be defined in parent
> POM
> > > and all module POMs can just reuse it like this:
> > >
> > > *my-module*
> > > *${app.version}*
> > >
> > > Igor
> >
> >
>
[jira] [Created] (IGNITE-3698) ODBC: Support LEN(string) function.
Vladimir Ozerov created IGNITE-3698:
---
Summary: ODBC: Support LEN(string) function.
Key: IGNITE-3698
URL: https://issues.apache.org/jira/browse/IGNITE-3698
Project: Ignite
Issue Type: Task
Components: odbc, SQL
Affects Versions: 1.7
Reporter: Vladimir Ozerov
Assignee: Andrew Mashenkov
Priority: Critical
Fix For: 1.8
*Problem*
ODBC has standard function LEN(string). We do not support it at the moment
because our H2 engine doesn't have this function. Instead, it has LENGTH
function [1].
We need to support LEN as well.
*Solution*
It is necessary to investigate how we can add "LEN" support. Most probably we
should implement custom H2 function [2] inside "core" module. It can be placed
in the package {{org.apache.ignite.internal.processors.query.h2.ext.func}} in
the module "ignite-indexing".
After that we should register it's alias inside the database, so that is LEN is
correctly routed to that function.
There is a chance that we can skip implementation of the new function and
directly route LEN alias to built-in LENGTH function. This is the most
preferred solution (if achievable). See {{org.h2.expression.Function}} class in
H2 JAR. It shows an example on how funcs are registered and mapped to SQL
literals. E.g., this is how {{LENGTH}} is mapped:
{code}
addFunction("LENGTH", LENGTH, 1, Value.LONG);
{code}
Something semantically similar can be found in {{GridSqlFunction}} and
{{GridSqlFunctionType}} classes in Ignite.
Please also make sure that proper tests are added.
[1] http://www.h2database.com/html/functions.html#length
[2] http://www.h2database.com/html/features.html#user_defined_functions
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3699) CreatedExpiryPolicy doesn't work if entry is loaded from store
Valentin Kulichenko created IGNITE-3699:
---
Summary: CreatedExpiryPolicy doesn't work if entry is loaded from
store
Key: IGNITE-3699
URL: https://issues.apache.org/jira/browse/IGNITE-3699
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.7
Reporter: Valentin Kulichenko
Fix For: 1.8
According to JCache spec, {{ExpiryPolicy.getExpiryForCreation()}} must be
triggered on {{get()}} operation if the entry is loaded from the store.
Currently this is not happening.
Test reproducing the issue is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3700) CacheWriter implementations should remove updated entries from the input collection
Valentin Kulichenko created IGNITE-3700:
---
Summary: CacheWriter implementations should remove updated entries
from the input collection
Key: IGNITE-3700
URL: https://issues.apache.org/jira/browse/IGNITE-3700
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 1.7
Reporter: Valentin Kulichenko
Fix For: 1.8
According to {{CacheWriter}} JavaDoc, bulk operations ({{writeAll}} and
{{deleteAll}}) should remove successful entries from the input collection:
{code}
* If this operation fails (by throwing an exception) after a partial success,
* the writer must remove any successfully written entries from the entries
* collection so that the caching implementation knows what succeeded and can
* mutate the cache.
{code}
We properly handle this in the cache store manager and throw
{{CachePartialUpdateException}} with the list of keys not removed from the
original collection. However, the implementations provided by Ignite
({{CacheStoreAdapter}}, {{CacheAbstractJdbcStore}}, etc.) ignore this and
simply iterate through entries without removing successful ones.
Proper implementation should use {{Iterator}} and use it to remove the entry
after successful update:
{code}
@Override public void writeAll(Collection> entries) throws CacheWriterException {
Iterator> it =
entries.iterator();
while (it.hasNext()) {
Cache.Entry entry = it.next();
// Do actual update (can throw and exception).
it.remove();
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3701) Ignite Maven project version number
Igor Rudyak created IGNITE-3701:
---
Summary: Ignite Maven project version number
Key: IGNITE-3701
URL: https://issues.apache.org/jira/browse/IGNITE-3701
Project: Ignite
Issue Type: Improvement
Reporter: Igor Rudyak
Each time after publishing new Ignite release and switching to development of
next version, version numbers are copy-pasted in all module POMs. It's better
just to define project version variable in one place to reuse it in module POMs.
For example, variable like ${app.version} could be defined in parent POM and
all module POMs can just reuse it like this:
my-module
${app.version}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Ignite Maven project version number
Ok, I created a ticket: https://issues.apache.org/jira/browse/IGNITE-3701
Igor
On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak wrote:
> Ok, I'll create a ticket and implement it.
>
> Igor
>
> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
> avinogra...@gridgain.com> wrote:
>
>> Hi All,
>>
>> We used this approach 1.5 years before, but had some problems with
>> assemblying and deploying.
>> I can't remember what type of problem it was, possible they are already
>> solved.
>>
>> I think we should refactor master branch as Igor described and check it
>> works.
>>
>> Igor,
>> could you please implement it, check assemblying works (Ignite Fabric
>> Maven
>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
>>
>>
>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda wrote:
>>
>> > Anton, would you mind providing your thoughts on this.
>> >
>> > —
>> > Denis
>> >
>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak wrote:
>> > >
>> > > Guys,
>> > >
>> > > Found that each time after publishing new Ignite release and
>> switching to
>> > > development of next version, version numbers are copy-pasted in all
>> > module
>> > > POMs. Isn't it better just to define project version variable in one
>> > > place(and change it in one place) to reuse it in module POMs?
>> > >
>> > > For example, variable like ${app.version} could be defined in parent
>> POM
>> > > and all module POMs can just reuse it like this:
>> > >
>> > > *my-module*
>> > > *${app.version}*
>> > >
>> > > Igor
>> >
>> >
>>
>
>
Contribution merged: IGNITE-3263 (Affinity function must check for null keys)
Saikat, Thanks a lot for keep making Apache Ignite better. I’ve just merged you recent improvements https://issues.apache.org/jira/browse/IGNITE-3263 Regards, Denis
[jira] [Created] (IGNITE-3702) Schema import utility: missing index type setter in java code generator
Alexey Kuznetsov created IGNITE-3702: Summary: Schema import utility: missing index type setter in java code generator Key: IGNITE-3702 URL: https://issues.apache.org/jira/browse/IGNITE-3702 Project: Ignite Issue Type: Bug Components: wizards Affects Versions: 1.6 Reporter: Alexey Kuznetsov Assignee: Alexey Kuznetsov Fix For: 1.8 XML generator has such setter, but Java - no. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] ignite pull request #961: IGNITE-3172 Ignite Maven project version number
GitHub user irudyak opened a pull request: https://github.com/apache/ignite/pull/961 IGNITE-3172 Ignite Maven project version number You can merge this pull request into a Git repository by running: $ git pull https://github.com/irudyak/ignite ignite-3701 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/961.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #961 commit 90af6ebc3b71add0326a52a8b426febd0441f45f Author: Igor Date: 2016-08-17T01:26:47Z IGNITE-3172 --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Ignite Maven project version number
Ok, created a pull request for this:
https://github.com/apache/ignite/pull/961
Igor
On Tue, Aug 16, 2016 at 3:12 PM, Igor Rudyak wrote:
> Ok, I created a ticket: https://issues.apache.org/jira/browse/IGNITE-3701
>
> Igor
>
> On Tue, Aug 16, 2016 at 8:34 AM, Igor Rudyak wrote:
>
>> Ok, I'll create a ticket and implement it.
>>
>> Igor
>>
>> On Tue, Aug 16, 2016 at 12:46 AM, Anton Vinogradov <
>> avinogra...@gridgain.com> wrote:
>>
>>> Hi All,
>>>
>>> We used this approach 1.5 years before, but had some problems with
>>> assemblying and deploying.
>>> I can't remember what type of problem it was, possible they are already
>>> solved.
>>>
>>> I think we should refactor master branch as Igor described and check it
>>> works.
>>>
>>> Igor,
>>> could you please implement it, check assemblying works (Ignite Fabric
>>> Maven
>>> Build Instructions section at DEVNOTES.txt) and create pullrequest?
>>>
>>>
>>> On Mon, Aug 15, 2016 at 8:46 PM, Denis Magda
>>> wrote:
>>>
>>> > Anton, would you mind providing your thoughts on this.
>>> >
>>> > —
>>> > Denis
>>> >
>>> > > On Aug 12, 2016, at 6:02 PM, Igor Rudyak wrote:
>>> > >
>>> > > Guys,
>>> > >
>>> > > Found that each time after publishing new Ignite release and
>>> switching to
>>> > > development of next version, version numbers are copy-pasted in all
>>> > module
>>> > > POMs. Isn't it better just to define project version variable in one
>>> > > place(and change it in one place) to reuse it in module POMs?
>>> > >
>>> > > For example, variable like ${app.version} could be defined in parent
>>> POM
>>> > > and all module POMs can just reuse it like this:
>>> > >
>>> > > *my-module*
>>> > > *${app.version}*
>>> > >
>>> > > Igor
>>> >
>>> >
>>>
>>
>>
>
[GitHub] ignite pull request #961: IGNITE-3701 Ignite Maven project version number
Github user irudyak closed the pull request at: https://github.com/apache/ignite/pull/961 --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] ignite pull request #961: IGNITE-3701 Ignite Maven project version number
GitHub user irudyak reopened a pull request: https://github.com/apache/ignite/pull/961 IGNITE-3701 Ignite Maven project version number You can merge this pull request into a Git repository by running: $ git pull https://github.com/irudyak/ignite ignite-3701 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/961.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #961 commit 90af6ebc3b71add0326a52a8b426febd0441f45f Author: Igor Date: 2016-08-17T01:26:47Z IGNITE-3172 --- 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 infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
