[jira] [Resolved] (JCRVLT-220) Include package type when assembling a package

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-220.
-
   Resolution: Fixed
Fix Version/s: 3.1.42

fixed in r1814557

> Include package type when assembling a package
> --
>
> Key: JCRVLT-220
> URL: https://issues.apache.org/jira/browse/JCRVLT-220
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Affects Versions: 3.1.40
>Reporter: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> Currently the package page can only be defined with external tools, but not 
> when assembling a package.
> it should be possible to:
> - specify the package type during build time
> - have a automatic detection of the package type, based on content or filter.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-195) Support OSGi bundle dependencies

[Konrad Windszus (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243473#comment-16243473
 ] 

Konrad Windszus commented on JCRVLT-195:


I am using the HTTP package manager ReST API. The package contains both the 
hook in one sub package (as OSGi bundle below one install folder) as well as 
the subpackage leveraging the hook. The only problem I see is that just 
ordering the packages is not enough here, as even after installing the sub 
package with the hook it takes some time until the bundle is finally picked up 
by the OSGi installer and correctly started. Only afterwards the hook is really 
ready for consumption by others.

> Support OSGi bundle dependencies
> 
>
> Key: JCRVLT-195
> URL: https://issues.apache.org/jira/browse/JCRVLT-195
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> FileVault Packages support both internal and external hooks. Internal hooks 
> are JARs which are part of the package itself. External hooks are provided 
> through some classloader (usually through the Bundle Classloader in an OSGi 
> context, https://issues.apache.org/jira/browse/JCRVLT-116). Installing a 
> package depending on an external hook class which is not found, leads to an 
> error.
> Therefore it would be beneficial to explicitly add a dependency from the 
> package referencing an external hook towards the OSGi bundle providing the 
> hook. Only that way it can be assured, that the installation of this package 
> is deferred until that bundle providing the hook is finally active. Currently 
> only package dependencies are supported though, which are not enough, as 
> there is a delay until the embedded bundle in a package is deployed as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-223) Update the OSGi DS annotations

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-223:
---

 Summary: Update the OSGi DS annotations
 Key: JCRVLT-223
 URL: https://issues.apache.org/jira/browse/JCRVLT-223
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: Packaging
Affects Versions: 3.1.40
Reporter: Tobias Bocanegra
 Fix For: 3.1.42






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (JCRVLT-225) vlt doesn't work anymore with latest jackrabbit

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-225:
---

Assignee: Tobias Bocanegra

> vlt doesn't work anymore with latest jackrabbit
> ---
>
> Key: JCRVLT-225
> URL: https://issues.apache.org/jira/browse/JCRVLT-225
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
>
> {code}
> $ vlt up
> Connecting via JCR remoting to http://localhost:4502/crx/server
> [ERROR] update: java.lang.NoSuchMethodError: 
> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCRVLT-197) AggregateImpl.includesProperty fails with multiple filter roots

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-197.
-
   Resolution: Fixed
Fix Version/s: 3.1.42

thanks for the patch [~volune]. I slightly modified it, since I didn't want to 
modify the public api too much. I also added tests for the generate source 
roundtrip.

please test if this solves you problems.

fixed in r1814551

> AggregateImpl.includesProperty fails with multiple filter roots
> ---
>
> Key: JCRVLT-197
> URL: https://issues.apache.org/jira/browse/JCRVLT-197
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Reporter: Jeremy Judeaux
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> If I set multiple filter roots in my configuration, properties will not be 
> handled correctly.
> Tested with 3.1.28 and trunk (about 3.1.40)
> Example of failing configuration:
> {code:xml}
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> Reproducing tests:
> (I copied the algorithm for simplicity. It would be easier to test if the 
> function is moved to {{WorkspaceFilter}})
> {code:java}
> package org.apache.jackrabbit.vault.fs.impl;
> import org.apache.jackrabbit.vault.fs.api.PathFilterSet;
> import org.apache.jackrabbit.vault.fs.api.WorkspaceFilter;
> import org.apache.jackrabbit.vault.fs.config.DefaultWorkspaceFilter;
> import org.apache.jackrabbit.vault.fs.filter.DefaultPathFilter;
> import org.junit.Assert;
> import org.junit.Test;
> public class AggregateImplTest {
> // Copied from AggregateImpl
> private boolean includesProperty(String propertyPath, WorkspaceFilter 
> workspaceFilter) {
> for (PathFilterSet filterSet : 
> workspaceFilter.getPropertyFilterSets()) {
> if (!filterSet.contains(propertyPath)) {
> return false;
> }
> }
> return true;
> }
> @Test
> public void testIncludesPropertyExpected() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set1 = new PathFilterSet("/foo");
> set1.seal();
> workspaceFilter.addPropertyFilterSet(set1);
> PathFilterSet set2 = new PathFilterSet("/bar");
> set2.addExclude(new DefaultPathFilter(".*/jcr:mixinTypes"));
> set2.seal();
> workspaceFilter.addPropertyFilterSet(set2);
> Assert.assertTrue(includesProperty("/foo/node/jcr:primaryType", 
> workspaceFilter));
> Assert.assertTrue(includesProperty("/foo/node/jcr:mixinTypes", 
> workspaceFilter));
> Assert.assertTrue(includesProperty("/bar/node/jcr:primaryType", 
> workspaceFilter));
> Assert.assertFalse(includesProperty("/bar/node/jcr:mixinTypes", 
> workspaceFilter));
> }
> @Test
> public void testIncludesPropertyCurrentlyWorking1() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set1 = new PathFilterSet("/foo");
> set1.seal();
> workspaceFilter.addPropertyFilterSet(set1);
> Assert.assertTrue(includesProperty("/foo/node/jcr:primaryType", 
> workspaceFilter));
> Assert.assertTrue(includesProperty("/foo/node/jcr:mixinTypes", 
> workspaceFilter));
> }
> @Test
> public void testIncludesPropertyCurrentlyWorking2() {
> DefaultWorkspaceFilter workspaceFilter = new DefaultWorkspaceFilter();
> PathFilterSet set2 = new PathFilterSet("/bar");
> set2.addExclude(new DefaultPathFilter(".*/jcr:mixinTypes"));
> set2.seal();
> workspaceFilter.addPropertyFilterSet(set2);
> Assert.assertTrue(includesProperty("/bar/node/jcr:primaryType", 
> workspaceFilter));
> Assert.assertFalse(includesProperty("/bar/node/jcr:mixinTypes", 
> workspaceFilter));
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-224) Use filevault-core instead of copy-pasting code

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-224:
---

 Summary: Use filevault-core instead of copy-pasting code
 Key: JCRVLT-224
 URL: https://issues.apache.org/jira/browse/JCRVLT-224
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.0
Reporter: Tobias Bocanegra


the plugin code contains some code duplication form filevault, like the 
DefaultWorkspaceFilter. Those should be removed and the filevault-core 
dependency should be used instead.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (JCRVLT-200) Vault should support suppressSnapshots property

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra reassigned JCRVLT-200:
---

Assignee: Tobias Bocanegra

> Vault should support suppressSnapshots property
> ---
>
> Key: JCRVLT-200
> URL: https://issues.apache.org/jira/browse/JCRVLT-200
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Affects Versions: 3.1.40
>Reporter: Mohit Arora
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> Currently, OSGI installer supports suppressSnapshots property where if a 
> content package has this property set then no snapshot is created for that 
> package while installing it in package manager.
> But on installing the same content package through package manager, snapshot 
> is created irrespective of the flag being set. JCR installer should also 
> support suppressSnapshots flag.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-195) Support OSGi bundle dependencies

[Tobias Bocanegra (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243411#comment-16243411
 ] 

Tobias Bocanegra commented on JCRVLT-195:
-

bq. Only that way it can be assured, that the installation of this package is 
deferred until that bundle providing the hook is finally active. 

[~kwin] how should this work? I assume you install a super package via http or 
package manager. the package contains various sub-packages and bundles. and one 
of the sub-packages contains a hook that needs the bundle. so now you want the 
entire installation to sleep until the bundle is active?

{noformat}
super-pkg
  |- hook-pkg
  |- bundle-with-hook
{noformat}

*or* are you using the OSGi package installer and need to ensure the proper 
dependency resolution there? (this would rather be a granite / sling issue)


> Support OSGi bundle dependencies
> 
>
> Key: JCRVLT-195
> URL: https://issues.apache.org/jira/browse/JCRVLT-195
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: Packaging
>Reporter: Konrad Windszus
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> FileVault Packages support both internal and external hooks. Internal hooks 
> are JARs which are part of the package itself. External hooks are provided 
> through some classloader (usually through the Bundle Classloader in an OSGi 
> context, https://issues.apache.org/jira/browse/JCRVLT-116). Installing a 
> package depending on an external hook class which is not found, leads to an 
> error.
> Therefore it would be beneficial to explicitly add a dependency from the 
> package referencing an external hook towards the OSGi bundle providing the 
> hook. Only that way it can be assured, that the installation of this package 
> is deferred until that bundle providing the hook is finally active. Currently 
> only package dependencies are supported though, which are not enough, as 
> there is a delay until the embedded bundle in a package is deployed as well.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCRVLT-200) Vault should support suppressSnapshots property

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-200.
-
Resolution: Won't Fix

Decided not to implement this. The problem is the following:

- if a user calls install() then it should create the snapshot, per definition.
- if a user calls extract() then it should not create the snapshot, per 
definition.
- if the package contains sub-packages, then SubPackageHandling property is 
used, as defined in JCRVLT-30

So maybe the missing part is that ability to deliberately only extract() a 
package via the CRX package manager.

> Vault should support suppressSnapshots property
> ---
>
> Key: JCRVLT-200
> URL: https://issues.apache.org/jira/browse/JCRVLT-200
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Affects Versions: 3.1.40
>Reporter: Mohit Arora
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> Currently, OSGI installer supports suppressSnapshots property where if a 
> content package has this property set then no snapshot is created for that 
> package while installing it in package manager.
> But on installing the same content package through package manager, snapshot 
> is created irrespective of the flag being set. JCR installer should also 
> support suppressSnapshots flag.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-226) vlt doesn't work with java 9

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-226:
---

 Summary: vlt doesn't work with java 9
 Key: JCRVLT-226
 URL: https://issues.apache.org/jira/browse/JCRVLT-226
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: vlt
Reporter: Tobias Bocanegra


{code}
$ vlt --version && vlt up
Jackrabbit FileVault [version 3.1.41-SNAPSHOT] Copyright 2013 by Apache 
Software Foundation. See LICENSE.txt for more information.
[ERROR] update: java.lang.IllegalArgumentException: 
org.apache.jackrabbit.vault.fs.api.RepositoryFactory is not an ImageIO SPI class
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-226) vlt doesn't work with java 9

[Tobias Bocanegra (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243367#comment-16243367
 ] 

Tobias Bocanegra commented on JCRVLT-226:
-

found solution from:
https://github.com/levigo/jbig2-imageio/pull/18

{quote}
In Java 9, javax.imageio.spi.ServiceRegistry checks if the requested service is 
an implementation of the Image I/O service provider interface. This module used 
the Image I/O service registry for loading external utility services like 
logging and caching. This is not an intended use and is now prohibited by the 
Java 9 runtime. javax.imageio.spi.ServiceRegistry uses 
'java.util.ServiceLoader' internally.

The lookups done by javax.imageio.spi.ServiceRegistry are replaced by that of 
'java.util.ServiceLoader'.
{quote}




> vlt doesn't work with java 9
> 
>
> Key: JCRVLT-226
> URL: https://issues.apache.org/jira/browse/JCRVLT-226
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Tobias Bocanegra
>
> {code}
> $ vlt --version && vlt up
> Jackrabbit FileVault [version 3.1.41-SNAPSHOT] Copyright 2013 by Apache 
> Software Foundation. See LICENSE.txt for more information.
> [ERROR] update: java.lang.IllegalArgumentException: 
> org.apache.jackrabbit.vault.fs.api.RepositoryFactory is not an ImageIO SPI 
> class
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCRVLT-226) vlt doesn't work with java 9

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-226.
-
   Resolution: Fixed
Fix Version/s: 3.1.42

fixed in r1814555

> vlt doesn't work with java 9
> 
>
> Key: JCRVLT-226
> URL: https://issues.apache.org/jira/browse/JCRVLT-226
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> {code}
> $ vlt --version && vlt up
> Jackrabbit FileVault [version 3.1.41-SNAPSHOT] Copyright 2013 by Apache 
> Software Foundation. See LICENSE.txt for more information.
> [ERROR] update: java.lang.IllegalArgumentException: 
> org.apache.jackrabbit.vault.fs.api.RepositoryFactory is not an ImageIO SPI 
> class
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JCRVLT-225) vlt doesn't work anymore with latest jackrabbit

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra resolved JCRVLT-225.
-
   Resolution: Fixed
Fix Version/s: 3.1.42

fixed in r1814554

> vlt doesn't work anymore with latest jackrabbit
> ---
>
> Key: JCRVLT-225
> URL: https://issues.apache.org/jira/browse/JCRVLT-225
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: vlt
>Reporter: Tobias Bocanegra
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
>
> {code}
> $ vlt up
> Connecting via JCR remoting to http://localhost:4502/crx/server
> [ERROR] update: java.lang.NoSuchMethodError: 
> org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-225) vlt doesn't work anymore with latest jackrabbit

[Tobias Bocanegra (JIRA)]

Tobias Bocanegra created JCRVLT-225:
---

 Summary: vlt doesn't work anymore with latest jackrabbit
 Key: JCRVLT-225
 URL: https://issues.apache.org/jira/browse/JCRVLT-225
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: vlt
Reporter: Tobias Bocanegra


{code}
$ vlt up
Connecting via JCR remoting to http://localhost:4502/crx/server
[ERROR] update: java.lang.NoSuchMethodError: 
org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
{code}




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Deleted] (JCRVLT-223) Update the OSGi DS annotations

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra deleted JCRVLT-223:



> Update the OSGi DS annotations
> --
>
> Key: JCRVLT-223
> URL: https://issues.apache.org/jira/browse/JCRVLT-223
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Reporter: Tobias Bocanegra
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

[Tobias Bocanegra (JIRA)]

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

Tobias Bocanegra updated JCRVLT-222:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

applied patch as-is in r1814547

> analyze-classes goal should be marked as ignored for m2e
> 
>
> Key: JCRVLT-222
> URL: https://issues.apache.org/jira/browse/JCRVLT-222
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: package-maven-plugin-1.0.1
>
> Attachments: 
> 0001-JCRVLT-222-analyze-classes-goal-should-be-marked-as-.patch
>
>
> The analyze-classes goal is currently bound to the 'process-classes' 
> lifecycle phase and causes m2e to raise an error since it's not mapped.
> It should be mapped to ignore, same as 'check-signature', as it does not make 
> sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.11

[Andrei Dulceanu]

 [X] +1 Release this package as Apache Jackrabbit Oak 1.7.11

where

[INFO] Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T22:39:06+03:00)
[INFO] OS name: "mac os x", version: "10.12.6", arch: "x86_64", family:
"mac"
[INFO] Java version: 1.8.0_65, vendor: Oracle Corporation

Andrei

2017-11-07 15:15 GMT+02:00 Davide Giannella :

> Please vote on releasing this package as Apache Jackrabbit Oak 1.7.11.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.7.11
> [ ] -1 Do not release this package because...
>
> D.
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.11

[Alex Deparvu]

[X] +1 Release this package as Apache Jackrabbit Oak 1.7.11


alex

On Tue, Nov 7, 2017 at 2:15 PM, Davide Giannella  wrote:

> A candidate for the Jackrabbit Oak 1.7.11 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.7.11/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/
> jackrabbit-oak-1.7.11/
>
> The SHA1 checksum of the archive is
> 445beb053b7f11b65d31e85da777b8d45b44f747.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> $ sh check-release.sh oak 1.7.11
> 445beb053b7f11b65d31e85da777b8d45b44f747
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.7.11.
> The vote is open for the next 72 hours and passes if a majority of at
> least three +1 Jackrabbit PMC votes are cast.
>
> [ ] +1 Release this package as Apache Jackrabbit Oak 1.7.11
> [ ] -1 Do not release this package because...
>
> D.
>

BUILD FAILURE: Jackrabbit Oak - Build # 953 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #953)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/953/ to 
view the results.

Changes:
[mreutegg] OAK-5028: Remove DocumentStore.update()

 

Test results:
1 tests failed.
FAILED:  
org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing[SegmentTar]

Error Message:
Just filled queue must not convert local->external expected:<6> but was:<4>

Stack Trace:
java.lang.AssertionError: Just filled queue must not convert local->external 
expected:<6> but was:<4>
at 
org.apache.jackrabbit.oak.jcr.observation.ObservationQueueFullWarnTest.testQueueFullThenFlushing(ObservationQueueFullWarnTest.java:347)

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.11

[Marcel Reutegger]

On 07/11/17 14:15, Davide Giannella wrote:

Please vote on releasing this package as Apache Jackrabbit Oak 1.7.11.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.


All checks OK.

+1 Release this package as Apache Jackrabbit Oak 1.7.11

[INFO] Apache Maven 3.3.9
[INFO] OS name: "linux", version: "4.4.0-97-generic", arch: "amd64", 
family: "unix"

[INFO] Java version: 1.8.0_151, vendor: Oracle Corporation

Regards
 Marcel

BUILD FAILURE: Jackrabbit Oak - Build # 952 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #952)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/952/ to 
view the results.

Changes:
[thomasm] OAK-301 Document Oak

[davide] [maven-release-plugin] prepare for next development iteration

[davide] [maven-release-plugin] prepare release jackrabbit-oak-1.7.11

[davide] Apache Jackrabbit Oak 1.7.11

wrong javadocs

[davide] Apache Jackrabbit Oak 1.7.11

release notes

[davide] Apache Jackrabbit Oak 1.7.11

missing licence header

 

Test results:
All tests passed

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.11

[Julian Reschke]

On 2017-11-07 14:15, Davide Giannella wrote:

...


[X] +1 Release this package as Apache Jackrabbit Oak 1.7.11

where:


[INFO] Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
2017-10-18T09:58:13+02:00)
[INFO] OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO] Java version: 9, vendor: Oracle Corporation


Best regards, Julian

[VOTE] Release Apache Jackrabbit Oak 1.7.11

[Davide Giannella]

A candidate for the Jackrabbit Oak 1.7.11 release is available at:

    https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.7.11/

The release candidate is a zip archive of the sources in:

   
https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.7.11/

The SHA1 checksum of the archive is
445beb053b7f11b65d31e85da777b8d45b44f747.

A staged Maven repository is available for review at:

    https://repository.apache.org/

The command for running automated checks against this release candidate is:

    $ sh check-release.sh oak 1.7.11
445beb053b7f11b65d31e85da777b8d45b44f747

Please vote on releasing this package as Apache Jackrabbit Oak 1.7.11.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

    [ ] +1 Release this package as Apache Jackrabbit Oak 1.7.11
    [ ] -1 Do not release this package because...

D.

BUILD FAILURE: Jackrabbit Oak - Build # 951 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #951)

Status: Failure

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/951/ to 
view the results.

Changes:
[frm] OAK-6896 - Log the initial size of the FileStore at startup

[frm] OAK-6890 - Fix SafeRunnable rethrow policy

SafeRunnable should never rethrow the Throwable it catches. While it might not
make sense in some cases - e.g. OutOfMemoryError - it prevents the SafeRunnable
from being unscheduled from the ScheduledExecutorService that runs it
periodically. Each SafeRunnable represents a background task that is important
for the health of the FileStore and should never be accidentally unscheduled.

 

Test results:
All tests passed

[jira] [Commented] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

[Tobias Bocanegra (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241686#comment-16241686
 ] 

Tobias Bocanegra commented on JCRVLT-222:
-

looks good to me. feel free to commit it. otherwise I will do it tomorrow.

> analyze-classes goal should be marked as ignored for m2e
> 
>
> Key: JCRVLT-222
> URL: https://issues.apache.org/jira/browse/JCRVLT-222
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: package-maven-plugin-1.0.1
>
> Attachments: 
> 0001-JCRVLT-222-analyze-classes-goal-should-be-marked-as-.patch
>
>
> The analyze-classes goal is currently bound to the 'process-classes' 
> lifecycle phase and causes m2e to raise an error since it's not mapped.
> It should be mapped to ignore, same as 'check-signature', as it does not make 
> sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated JCRVLT-222:
---
Attachment: 0001-JCRVLT-222-analyze-classes-goal-should-be-marked-as-.patch

[~tripod] - here's a trivial patch which fixes this issue

> analyze-classes goal should be marked as ignored for m2e
> 
>
> Key: JCRVLT-222
> URL: https://issues.apache.org/jira/browse/JCRVLT-222
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: package-maven-plugin-1.0.1
>
> Attachments: 
> 0001-JCRVLT-222-analyze-classes-goal-should-be-marked-as-.patch
>
>
> The analyze-classes goal is currently bound to the 'process-classes' 
> lifecycle phase and causes m2e to raise an error since it's not mapped.
> It should be mapped to ignore, same as 'check-signature', as it does not make 
> sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated JCRVLT-222:
---
Status: Patch Available  (was: Open)

> analyze-classes goal should be marked as ignored for m2e
> 
>
> Key: JCRVLT-222
> URL: https://issues.apache.org/jira/browse/JCRVLT-222
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>  Components: package maven plugin
>Affects Versions: package-maven-plugin-1.0.0
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: package-maven-plugin-1.0.1
>
>
> The analyze-classes goal is currently bound to the 'process-classes' 
> lifecycle phase and causes m2e to raise an error since it's not mapped.
> It should be mapped to ignore, same as 'check-signature', as it does not make 
> sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (JCRVLT-222) analyze-classes goal should be marked as ignored for m2e

[Robert Munteanu (JIRA)]

Robert Munteanu created JCRVLT-222:
--

 Summary: analyze-classes goal should be marked as ignored for m2e
 Key: JCRVLT-222
 URL: https://issues.apache.org/jira/browse/JCRVLT-222
 Project: Jackrabbit FileVault
  Issue Type: Bug
  Components: package maven plugin
Affects Versions: package-maven-plugin-1.0.0
Reporter: Robert Munteanu
Priority: Minor
 Fix For: package-maven-plugin-1.0.1


The analyze-classes goal is currently bound to the 'process-classes' lifecycle 
phase and causes m2e to raise an error since it's not mapped.

It should be mapped to ignore, same as 'check-signature', as it does not make 
sense in an IDE context.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCR-3241) Jackrabbit does not deploy on JBoss AS 7.1.0 Final

[Julian Reschke (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-3241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241678#comment-16241678
 ] 

Julian Reschke commented on JCR-3241:
-

If you are interested in JCA then please the previous comments, see whether the 
suggested change helps, and supply a patch.

> Jackrabbit does not deploy on JBoss AS 7.1.0 Final
> --
>
> Key: JCR-3241
> URL: https://issues.apache.org/jira/browse/JCR-3241
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jca
>Affects Versions: 2.2.10
>Reporter: Claudiu Muresan
>
> When deploying Jackrabbit JCA rar (resource adapter archive) on JBoss 7.1.0 
> final we have the following errors:
>   Section: 19.4.2
>   Description: A ResourceAdapter must implement a "public int hashCode()" 
> method.
>   Code: org.apache.jackrabbit.jca.JCAResourceAdapter
>   Severity: ERROR
>   Section: 19.4.2
>   Description: A ResourceAdapter must implement a "public boolean 
> equals(Object)" method.
>   Code: org.apache.jackrabbit.jca.JCAResourceAdapter
> JBoss ironjacamar runs a validation sequence on the JCAResourceAdapter which 
> seems to not conform to EE6 specifications.
> I tried with latest jackrabbit version and I have the same result.
> I need to use jackrabbit with JBoss 7.1.0 so this issue is kind of blocking. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: garbage collector in mongo document node store

[Marcel Reutegger]

Hi Marco,

On 05/11/17 18:37, Marco Piovesana wrote:
I've seen that there are three types of garbage collectors: version, 
journal and blob. Do I have to call them all?


No, you only have to take care of scheduling the Revision GC and the 
Blob GC. The Journal GC is scheduled automatically by the implementation.



If yes, there's a specific order that I should keep? For my trial I
did this:


The Blob GC will potentially be able to remove more blobs when scheduled 
after the Revision GC. However, a common schedule I see is Revision GC 
once a day and Blob GC once a week (e.g. on the weekend). So it doesn't 
matter that much which one runs first.



documentNodeStore.getVersionGarbageCollector().gc(1, TimeUnit.DAYS);


This works, but I would recommend you use the RepositoryManagementMBean, 
which is considered public and stable, whereas the method you are using 
is considered internal and subject to change between releases.


documentNodeStore.getJournalGarbageCollector().gc(1, TimeUnit.DAYS); 


As mentioned already, this is not necessary.

long oneDay = TimeUnit.SECONDS.convert(1, TimeUnit.DAYS); 
documentNodeStore.createBlobGarbageCollector(oneDay,
ClusterRepositoryInfo. 
getOrCreateId(documentNodeStore)).collectGarbage(false);


My recommendation again is to use RepositoryManagementMBean. There's a 
startDataStoreGC() method. This avoids using implementation specific 
classes.


Regards
 Marcel