[jira] [Commented] (OAK-7413) Build Jackrabbit Oak #1376 failed
[ https://issues.apache.org/jira/browse/OAK-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436796#comment-16436796 ] Hudson commented on OAK-7413: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1378|https://builds.apache.org/job/Jackrabbit%20Oak/1378/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1378/console] > Build Jackrabbit Oak #1376 failed > - > > Key: OAK-7413 > URL: https://issues.apache.org/jira/browse/OAK-7413 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1376 has failed. > First failed run: [Jackrabbit Oak > #1376|https://builds.apache.org/job/Jackrabbit%20Oak/1376/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1376/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436775#comment-16436775
]
Maksim Kviatkouski commented on OAK-6209:
-
Just realized I have a question about approached you proposed to deal with
output. If I create dummy {{OutputStream}} that discards all the output I still
need a way to output essential information like stats. What do you think is the
best way to deal with it? I can think of two solutions:
- Since "must have" output is printed in a very limited number of cases I can
refactor it to make call like ((FilteringPrintStream)
System.out.println)(formattedStatsObj, true) assuming that FilteringPrintStream
will not discard that output due to flag passed.
- Somehow make BenchmarkOutputStrategy to set system output back to regular
output and change it back to what it was after it's done working. I don't like
this approach though since it changes state of a globally available object
which is not really easy to deal with later.
Please let me know if you have more elegant solution.
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Attachments: oak-6209.patch, sample-machine-readable-output.txt
>
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436757#comment-16436757
]
Maksim Kviatkouski edited comment on OAK-6209 at 4/13/18 3:45 AM:
--
[~frm], I do really appreciate your time reviewing my patch and commenting it.
I agree on all points and have only a few points to clarify:
I love the idea of using {{CompositeOutputStrategy}}. It will make code more
elegant indeed. I feel that "noop" strategy class may not be needed. I will
simply have one strategy inside of my {{CompositeOutputStrategy}} printing to
console instead of having both: console and csv printer. What do you think?
Just thinking out loud to make sure I understood you right.
Totally agree on making {{BenchmarkOutputStrategy}} reusable. Now I
instantiate one or even two strategies per each test run which is absolutely
unnecessary.
I didn't feel very good myself rewriting all those calls to {{System.out}}
only to add "if" to them. My bad, I got a bit rusty with real-world java
programming, so didn't think about this option.
All very good points, Thanks once again. I'll have patch ready in a few days.
was (Author: maksim_kviatkouski):
[~frm], I do really appreciate your time reviewing my patch and commenting it.
I agree on all points and have only a few points to clarify:
I love the idea of using {{CompositeOutputStrategy}}. It will make code more
elegant indeed. I feel that "noop" strategy class may not be needed. I will
simply have one strategy inside of my {{CompositeOutputStrategy}} printing to
console instead of having both: console and csv printer. What do you think?
Just thinking out loud to make sure I understood you right.
Totally agree on making {{BenchmarkOutputStrategy}} reusable. Now I instantiate
one or even two strategies per each test run which is absolutely unnecessary.
I didn't feel very good myself rewriting all those calls to {{System.out}} only
to add "if" to them. My bad, I got a bit rusty with real-world java
programming, so didn't think about this option.
All very good points, Thanks once again. I'll have patch ready in a few days.
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Attachments: oak-6209.patch, sample-machine-readable-output.txt
>
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436757#comment-16436757
]
Maksim Kviatkouski edited comment on OAK-6209 at 4/13/18 3:44 AM:
--
[~frm], I do really appreciate your time reviewing my patch and commenting it.
I agree on all points and have only a few points to clarify:
* I love the idea of using {{CompositeOutputStrategy}}. It will make code more
elegant indeed. I feel that "noop" strategy class may not be needed. I will
simply have one strategy inside of my {{CompositeOutputStrategy}} printing to
console instead of having both: console and csv printer. What do you think?
Just thinking out loud to make sure I understood you right.
- Totally agree on making {{BenchmarkOutputStrategy}} reusable. Now I
instantiate one or even two strategies per each test run which is absolutely
unnecessary.
- I didn't feel very good myself rewriting all those calls to {{System.out}}
only to add "if" to them. My bad, I got a bit rusty with real-world java
programming, so didn't think about this option.
All very good points, Thanks once again. I'll have patch ready in a few days.
was (Author: maksim_kviatkouski):
[~frm], I do really appreciate your time reviewing my patch and commenting it.
I agree on all points and have only a few points to clarify:
- I love the idea of using {{CompositeOutputStrategy}}. It will make code more
elegant indeed. I feel that "noop" strategy class may not be needed. I will
simply have one strategy inside of my {{CompositeOutputStrategy}} printing to
console instead of having both: console and csv printer. What do you think?
Just thinking out loud to make sure I understood you right.
- Totally agree on making {{BenchmarkOutputStrategy}} reusable. Now I
instantiate one or even two strategies per each test run which is absolutely
unnecessary.
- I didn't feel very good myself rewriting all those calls to {{System.out}}
only to add "if" to them. My bad, I got a bit rusty with real-world java
programming, so didn't think about this option.
All very good points, Thanks once again. I'll have patch ready in a few days.
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Attachments: oak-6209.patch, sample-machine-readable-output.txt
>
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436757#comment-16436757
]
Maksim Kviatkouski commented on OAK-6209:
-
[~frm], I do really appreciate your time reviewing my patch and commenting it.
I agree on all points and have only a few points to clarify:
- I love the idea of using {{CompositeOutputStrategy}}. It will make code more
elegant indeed. I feel that "noop" strategy class may not be needed. I will
simply have one strategy inside of my {{CompositeOutputStrategy}} printing to
console instead of having both: console and csv printer. What do you think?
Just thinking out loud to make sure I understood you right.
- Totally agree on making {{BenchmarkOutputStrategy}} reusable. Now I
instantiate one or even two strategies per each test run which is absolutely
unnecessary.
- I didn't feel very good myself rewriting all those calls to {{System.out}}
only to add "if" to them. My bad, I got a bit rusty with real-world java
programming, so didn't think about this option.
All very good points, Thanks once again. I'll have patch ready in a few days.
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Attachments: oak-6209.patch, sample-machine-readable-output.txt
>
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436757#comment-16436757
]
Maksim Kviatkouski edited comment on OAK-6209 at 4/13/18 3:44 AM:
--
[~frm], I do really appreciate your time reviewing my patch and commenting it.
I agree on all points and have only a few points to clarify:
I love the idea of using {{CompositeOutputStrategy}}. It will make code more
elegant indeed. I feel that "noop" strategy class may not be needed. I will
simply have one strategy inside of my {{CompositeOutputStrategy}} printing to
console instead of having both: console and csv printer. What do you think?
Just thinking out loud to make sure I understood you right.
Totally agree on making {{BenchmarkOutputStrategy}} reusable. Now I instantiate
one or even two strategies per each test run which is absolutely unnecessary.
I didn't feel very good myself rewriting all those calls to {{System.out}} only
to add "if" to them. My bad, I got a bit rusty with real-world java
programming, so didn't think about this option.
All very good points, Thanks once again. I'll have patch ready in a few days.
was (Author: maksim_kviatkouski):
[~frm], I do really appreciate your time reviewing my patch and commenting it.
I agree on all points and have only a few points to clarify:
* I love the idea of using {{CompositeOutputStrategy}}. It will make code more
elegant indeed. I feel that "noop" strategy class may not be needed. I will
simply have one strategy inside of my {{CompositeOutputStrategy}} printing to
console instead of having both: console and csv printer. What do you think?
Just thinking out loud to make sure I understood you right.
- Totally agree on making {{BenchmarkOutputStrategy}} reusable. Now I
instantiate one or even two strategies per each test run which is absolutely
unnecessary.
- I didn't feel very good myself rewriting all those calls to {{System.out}}
only to add "if" to them. My bad, I got a bit rusty with real-world java
programming, so didn't think about this option.
All very good points, Thanks once again. I'll have patch ready in a few days.
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Attachments: oak-6209.patch, sample-machine-readable-output.txt
>
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7408) LuceneIndexProviderService uses default tracker constructor with disabled CoR
[
https://issues.apache.org/jira/browse/OAK-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16436690#comment-16436690
]
Vikas Saurabh commented on OAK-7408:
[~rombert], [~chetanm], I had to resort to reflection to test that reader
factory still get correct {{MountInfoProvider}}. I was wondering if default
mount could have a utility method to throw unsupported exception if the tests
says that default mount info provider must not be constructed Or, any other
ideas to have a wider test coverage.
> LuceneIndexProviderService uses default tracker constructor with disabled CoR
> -
>
> Key: OAK-7408
> URL: https://issues.apache.org/jira/browse/OAK-7408
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.2, 1.6.11
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.9.0, 1.10
>
>
> {{LuceneIndexProviderService}} creates default constructor for tracker when
> CoR is disabled. This leads to usage of deafult mount provider for querying.
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java#L526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (OAK-7408) LuceneIndexProviderService uses default tracker constructor with disabled CoR
[
https://issues.apache.org/jira/browse/OAK-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh resolved OAK-7408.
Resolution: Fixed
Fix Version/s: 1.9.0
Fixed in trunk at [r1829026|https://svn.apache.org/r1829026].
> LuceneIndexProviderService uses default tracker constructor with disabled CoR
> -
>
> Key: OAK-7408
> URL: https://issues.apache.org/jira/browse/OAK-7408
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.2, 1.6.11
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.9.0, 1.10
>
>
> {{LuceneIndexProviderService}} creates default constructor for tracker when
> CoR is disabled. This leads to usage of deafult mount provider for querying.
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java#L526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7413) Build Jackrabbit Oak #1376 failed
[ https://issues.apache.org/jira/browse/OAK-7413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435769#comment-16435769 ] Hudson commented on OAK-7413: - Build is still failing. Failed run: [Jackrabbit Oak #1377|https://builds.apache.org/job/Jackrabbit%20Oak/1377/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1377/console] > Build Jackrabbit Oak #1376 failed > - > > Key: OAK-7413 > URL: https://issues.apache.org/jira/browse/OAK-7413 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1376 has failed. > First failed run: [Jackrabbit Oak > #1376|https://builds.apache.org/job/Jackrabbit%20Oak/1376/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1376/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7414) oak-it-osgi fails on Java 10
Julian Reschke created OAK-7414:
---
Summary: oak-it-osgi fails on Java 10
Key: OAK-7414
URL: https://issues.apache.org/jira/browse/OAK-7414
Project: Jackrabbit Oak
Issue Type: Bug
Components: it
Reporter: Julian Reschke
Fix For: 1.10
{noformat}
ERROR: Bundle org.ops4j.pax.exam [1] Error starting
link:classpath:META-INF/links/org.ops4j.pax.exam.link
(org.osgi.framework.BundleException: Unable to resolve org.ops4j.pax.exam [1](R
1.0): missing requirement [org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))
[caused by: Unable to resolve org.ops4j.base [5](R 5.0): missing requirement
[org.ops4j.base [5](R 5.0)] osgi.wiring.package;
(osgi.wiring.package=javax.net.ssl)] Unresolved requirements:
[[org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))])
org.osgi.framework.BundleException: Unable to resolve org.ops4j.pax.exam [1](R
1.0): missing requirement [org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))
[caused by: Unable to resolve org.ops4j.base [5](R 5.0): missing requirement
[org.ops4j.base [5](R 5.0)] osgi.wiring.package;
(osgi.wiring.package=javax.net.ssl)] Unresolved requirements:
[[org.ops4j.pax.exam [1](R 1.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.ops4j.lang)(version>=1.4.0)(!(version>=2.0.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4148)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2118)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.base/java.lang.Thread.run(Thread.java:844)
ERROR: Bundle org.ops4j.pax.exam.inject [2] Error starting
link:classpath:META-INF/links/org.ops4j.pax.exam.inject.link
(org.osgi.framework.BundleException: Unable to resolve
org.ops4j.pax.exam.inject [2](R 2.0): missing requirement
[org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused
by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0):
missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)]
osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved
requirements: [[org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0)))])
org.osgi.framework.BundleException: Unable to resolve org.ops4j.pax.exam.inject
[2](R 2.0): missing requirement [org.ops4j.pax.exam.inject [2](R 2.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused
by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0):
missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)]
osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved
requirements: [[org.ops4j.pax.exam.inject [2](R 2.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0)))]
at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4148)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2118)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1372)
at
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:308)
at java.base/java.lang.Thread.run(Thread.java:844)
ERROR: Bundle org.ops4j.pax.exam.extender.service [3] Error starting
link:classpath:META-INF/links/org.ops4j.pax.extender.service.link
(org.osgi.framework.BundleException: Unable to resolve
org.ops4j.pax.exam.extender.service [3](R 3.0): missing requirement
[org.ops4j.pax.exam.extender.service [3](R 3.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused
by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0):
missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)]
osgi.wiring.package; (osgi.wiring.package=javax.xml.parsers)] Unresolved
requirements: [[org.ops4j.pax.exam.extender.service [3](R 3.0)]
osgi.wiring.package;
(&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0)))])
org.osgi.framework.BundleException: Unable to resolve
org.ops4j.pax.exam.extender.service [3](R 3.0): missing requirement
[org.ops4j.pax.exam.extender.service [3](R 3.0)] osgi.wiring.package;
(&(osgi.wiring.package=org.slf4j)(version>=1.4.0)(!(version>=2.0.0))) [caused
by: Unable to resolve org.ops4j.pax.logging.pax-logging-api [19](R 19.0):
missing requirement [org.ops4j.pax.logging.pax-logging-api [19](R 19.0)]
[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435644#comment-16435644 ] Julian Reschke commented on OAK-7406: - trunk: [r1828981|http://svn.apache.org/r1828981] > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.9.0, 1.10 > > Attachments: OAK-7406.diff, OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-7406. - Resolution: Fixed Assignee: Julian Reschke Fix Version/s: 1.10 1.9.0 > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.9.0, 1.10 > > Attachments: OAK-7406.diff, OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7413) Build Jackrabbit Oak #1376 failed
Hudson created OAK-7413: --- Summary: Build Jackrabbit Oak #1376 failed Key: OAK-7413 URL: https://issues.apache.org/jira/browse/OAK-7413 Project: Jackrabbit Oak Issue Type: Bug Components: continuous integration Reporter: Hudson No description is provided The build Jackrabbit Oak #1376 has failed. First failed run: [Jackrabbit Oak #1376|https://builds.apache.org/job/Jackrabbit%20Oak/1376/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1376/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435507#comment-16435507 ] Julian Reschke commented on OAK-7406: - New patch that should cover all subprojects: https://issues.apache.org/jira/secure/attachment/12918749/OAK-7406.diff > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-7406.diff, OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-7406: Attachment: OAK-7406.diff > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-7406.diff, OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7405) Build Jackrabbit Oak #1372 failed
[ https://issues.apache.org/jira/browse/OAK-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435490#comment-16435490 ] Hudson commented on OAK-7405: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1375|https://builds.apache.org/job/Jackrabbit%20Oak/1375/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1375/console] > Build Jackrabbit Oak #1372 failed > - > > Key: OAK-7405 > URL: https://issues.apache.org/jira/browse/OAK-7405 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1372 has failed. > First failed run: [Jackrabbit Oak > #1372|https://builds.apache.org/job/Jackrabbit%20Oak/1372/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1372/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7412) Make oak-solr extend from oak-search
Tommaso Teofili created OAK-7412: Summary: Make oak-solr extend from oak-search Key: OAK-7412 URL: https://issues.apache.org/jira/browse/OAK-7412 Project: Jackrabbit Oak Issue Type: Technical task Components: oak-search Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.10 Once Oak Search module is ready, Oak Solr should be refactored so that it extends from oak-search SPIs. Both implementation and extensive testing (regression, performance) should be conducted to make sure nothing is lost during this transition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7411) Make oak-lucene extend from oak-search
Tommaso Teofili created OAK-7411: Summary: Make oak-lucene extend from oak-search Key: OAK-7411 URL: https://issues.apache.org/jira/browse/OAK-7411 Project: Jackrabbit Oak Issue Type: Technical task Components: oak-search Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.10 Once Oak Search module is ready, Oak Lucene should be refactored so that it extends from _oak-search_ SPIs. Both implementation and extensive testing (regression, performance) should be conducted to make sure nothing is lost during this transition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7410) Define SPIs for Oak Search module
Tommaso Teofili created OAK-7410: Summary: Define SPIs for Oak Search module Key: OAK-7410 URL: https://issues.apache.org/jira/browse/OAK-7410 Project: Jackrabbit Oak Issue Type: Technical task Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.10 Abstract IndexEditor and QueryIndex implementations and SPIs should be created for Oak Search module. Those classes should be then reused / extended by implementors in and outside Oak . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (OAK-7409) Move Lucene agnostic utilities out of oak-lucene into oak-search
Tommaso Teofili created OAK-7409: Summary: Move Lucene agnostic utilities out of oak-lucene into oak-search Key: OAK-7409 URL: https://issues.apache.org/jira/browse/OAK-7409 Project: Jackrabbit Oak Issue Type: Technical task Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 1.9.0 The _oak-lucene_ module contains abstractions and utilities that are Lucene agnostic and that would be useful in the new _oak-search_ module to be possibly reused by _oak-search_ implementors. One example is the aggregation code, but also the stored index tracking code and base test classes might be useful for other indexers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-3336) Abstract a full text index implementation to be extended by Lucene and Solr
[ https://issues.apache.org/jira/browse/OAK-3336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435404#comment-16435404 ] Tommaso Teofili commented on OAK-3336: -- copied some Lucene agnostic classes from _oak-lucene_ to _oak-search_ in r1828972. > Abstract a full text index implementation to be extended by Lucene and Solr > --- > > Key: OAK-3336 > URL: https://issues.apache.org/jira/browse/OAK-3336 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query, solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili >Priority: Major > Fix For: 1.10 > > > Current Lucene and Solr indexes implement quite a no. of features according > to their specific APIs, design and implementation. However in the long run, > while differences in APIs and implementations will / can of course stay, the > difference in design can make it hard to keep those features on par. > It'd be therefore nice to make it possible to abstract as much of design and > implementation bits as possible in an abstract full text implementation which > Lucene and Solr would extend according to their specifics. > An example advantage of this is that index time aggregation will be > implemented only once and therefore any bugfixes and improvements in that > area will be done in the abstract implementation rather than having to do > that in two places. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7340) Remove SecurityProviderImpl usage from tests
[
https://issues.apache.org/jira/browse/OAK-7340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435389#comment-16435389
]
Alex Deparvu commented on OAK-7340:
---
forgot to set the root/tree providers to the {{AbstractSecurityTest}} tests
([r1828971|http://svn.apache.org/viewvc?rev=1828971=rev])
> Remove SecurityProviderImpl usage from tests
>
>
> Key: OAK-7340
> URL: https://issues.apache.org/jira/browse/OAK-7340
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, security
>Reporter: Alex Deparvu
>Assignee: Alex Deparvu
>Priority: Major
> Fix For: 1.9.0, 1.10
>
> Attachments: docs.patch
>
>
> Remove usage of {{SecurityProviderImpl}} from tests so we can eventually drop
> it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435277#comment-16435277 ] Robert Munteanu commented on OAK-7406: -- [~reschke] - that might be an issue with Maven plug-in inheritance of maybe a side effect of how the maven-bundle-plugin reads configurations. But I guess that we don't want automatic inheritance of an export definition - maybe not all modules use it, but rather a way of saying "when importing com.google.common.*, use this version range ". Which I don't know can work. IMO defining the import range centrally and then using the property in specific modules is OK. > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435274#comment-16435274 ] Julian Reschke commented on OAK-7406: - [~rombert] - yes, that works (see POC). What doesn't seem to work is putting the into the parent pom. > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (OAK-7408) LuceneIndexProviderService uses default tracker constructor with disabled CoR
[
https://issues.apache.org/jira/browse/OAK-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7408:
---
Affects Version/s: 1.8.2
1.6.11
> LuceneIndexProviderService uses default tracker constructor with disabled CoR
> -
>
> Key: OAK-7408
> URL: https://issues.apache.org/jira/browse/OAK-7408
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.8.2, 1.6.11
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.10
>
>
> {{LuceneIndexProviderService}} creates default constructor for tracker when
> CoR is disabled. This leads to usage of deafult mount provider for querying.
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java#L526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (OAK-7408) LuceneIndexProviderService uses default tracker constructor with disabled CoR
[
https://issues.apache.org/jira/browse/OAK-7408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7408:
---
Fix Version/s: 1.10
> LuceneIndexProviderService uses default tracker constructor with disabled CoR
> -
>
> Key: OAK-7408
> URL: https://issues.apache.org/jira/browse/OAK-7408
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.10
>
>
> {{LuceneIndexProviderService}} creates default constructor for tracker when
> CoR is disabled. This leads to usage of deafult mount provider for querying.
> \[0]:
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java#L526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (OAK-7408) LuceneIndexProviderService uses default tracker constructor with disabled CoR
Vikas Saurabh created OAK-7408:
--
Summary: LuceneIndexProviderService uses default tracker
constructor with disabled CoR
Key: OAK-7408
URL: https://issues.apache.org/jira/browse/OAK-7408
Project: Jackrabbit Oak
Issue Type: Bug
Components: lucene
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
{{LuceneIndexProviderService}} creates default constructor for tracker when CoR
is disabled. This leads to usage of deafult mount provider for querying.
\[0]:
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LuceneIndexProviderService.java#L526
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6209) The benchmark runner should produce machine-friendly output
[
https://issues.apache.org/jira/browse/OAK-6209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435127#comment-16435127
]
Francesco Mari commented on OAK-6209:
-
[~maksim_kviatkouski], I just finished to have a look at your patch. I have a
couple of comments, I hope we can discuss them together. Forgive my verbosity!
The work around {{BenchmarkOutputStrategy}} makes a lot of sense. I would like
to propose the following changes. I noticed that {{AbstractTest}} uses both an
{{outputStrategy}} and an optional {{csvStrategy}}, which is set only when a
CSV file must be generated. What do you think about implementing a
{{CompositeBenchmarkOutputStrategy}}, in the same spirit as
{{o.a.j.o.spi.commit.CompositeHook}}? This way you can avoid chaining the calls
of {{outputStrategy}} and {{csvStrategy}}, remembering to always wrap the
latter in an if statement. Actually, you could get rid of the if statement
altogether by creating a dummy implementation of {{BenchmarkOutputStrategy}},
whose methods do nothing. This way, if no CVS file is needed, you can simply
pass the dummy implementation instead of handling special cases because of
null. You probably already guessed that I took inspiration from
{{o.a.j.o.spi.commit.EmptyHook}}.
In order for {{BenchmarkOutputStrategy}} to be reusable across test
invocations, what do you think about having its methods accept an
{{AbstractTest}} parameter? This way you could instantiate the strategy (or
strategies) once during the setup of the benchmark runner, and use it for every
following benchmark run. The code in {{AbstractTest}} can simply call the
strategy as {{strategy.doSomething(this)}}.
While I understand your needs, I was a bit daunted at the amount of changes
necessary to get rid of the usages of {{System.out}}. What about redirecting
the standard output stream by using {{System#setOut}}? During the benchmark
runner setup, if the {{report}} option is not specified, you can simply create
a dummy {{OutputStream}} that discards all the output, create a new
{{PrintStream}} based on that {{OutputStream}}, and pass that {{PrintStream}}
to {{System#setOut}}. This way you don't need {{FilterPrinter}} and avoid
tedious changes in every benchmark.
> The benchmark runner should produce machine-friendly output
> ---
>
> Key: OAK-6209
> URL: https://issues.apache.org/jira/browse/OAK-6209
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Francesco Mari
>Assignee: Francesco Mari
>Priority: Major
> Attachments: oak-6209.patch, sample-machine-readable-output.txt
>
>
> The benchmark runner currently produce output in the following format.
> {noformat}
> Apache Jackrabbit Oak 1.8-SNAPSHOT
> # LoginTestC min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 494 522 552 631
>115
> # LoginLogoutTest C min 10% 50% 90% max
> N
> Oak-Segment-Tar1 472 479 513 543 568
>118
> {noformat}
> While this format is well formatted and easy to read, it's a pain to process
> with standard command line utilities. The benchmark runner should give the
> possibility to produce machine-friendly output, like the following.
> {noformat}
> LoginTest,Oak-Segment-Tar,1,472,494,522,552,631,115
> LoginLogoutTest,Oak-Segment-Tar,1,472,479,513,543,568,118
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435069#comment-16435069 ] Robert Munteanu commented on OAK-7406: -- [~reschke] - inheritance _should_ work. At least you should be able to define the property in the parent pom and then use it in the modules that need it. > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7405) Build Jackrabbit Oak #1372 failed
[ https://issues.apache.org/jira/browse/OAK-7405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16435009#comment-16435009 ] Hudson commented on OAK-7405: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1374|https://builds.apache.org/job/Jackrabbit%20Oak/1374/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1374/console] > Build Jackrabbit Oak #1372 failed > - > > Key: OAK-7405 > URL: https://issues.apache.org/jira/browse/OAK-7405 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1372 has failed. > First failed run: [Jackrabbit Oak > #1372|https://builds.apache.org/job/Jackrabbit%20Oak/1372/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1372/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7406) relax guava version range in Import-Package declarations
[ https://issues.apache.org/jira/browse/OAK-7406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16434984#comment-16434984 ] Julian Reschke commented on OAK-7406: - [~chetanm] - i tried to put it into oak-parent, but it doesn't seem to get inherited... > relax guava version range in Import-Package declarations > > > Key: OAK-7406 > URL: https://issues.apache.org/jira/browse/OAK-7406 > Project: Jackrabbit Oak > Issue Type: Technical task >Reporter: Julian Reschke >Priority: Major > Attachments: OAK-7406.diff > > > We should relax the Guava version to the range that we test with, that is > 15.0 to 21 excl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
