Re: Minimum JDK version

[Julian Reschke]

On 2016-09-12 14:09, Marcel Reutegger wrote:

Hi,

On 12/09/16 13:14, Chetan Mehrotra wrote:

I think Marcel created OAK-4791 for the same. So that should take care
of enforcing this constraing


Indeed. For trunk I just enabled the check against the 1.7 signature.

I will backport the plugin configuration to the branches and change
the version to 1.6 if possible. Otherwise we do it once 1.7 usages
are removed on the branches.

Regards
 Marcel


Thanks for taking care of this!

Re: Minimum JDK version

[Marcel Reutegger]

Hi,

On 12/09/16 13:14, Chetan Mehrotra wrote:

I think Marcel created OAK-4791 for the same. So that should take care
of enforcing this constraing


Indeed. For trunk I just enabled the check against the 1.7 signature.

I will backport the plugin configuration to the branches and change
the version to 1.6 if possible. Otherwise we do it once 1.7 usages
are removed on the branches.

Regards
 Marcel

Re: Minimum JDK version

[Chetan Mehrotra]

I think Marcel created OAK-4791 for the same. So that should take care
of enforcing this constraing
Chetan Mehrotra


On Mon, Sep 12, 2016 at 4:40 PM, Stefan Seifert  wrote:
> in sling we use the animal sniffer plugin for exactly this purpose [1].
> it checks that the compiled codes only uses signatures available in the 
> configured jdk.
>
> stefan
>
> [1] http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/
>
>>-Original Message-
>>From: Tomek Rekawek [mailto:reka...@adobe.com]
>>Sent: Monday, September 12, 2016 1:06 PM
>>To: oak-dev@jackrabbit.apache.org
>>Subject: Re: Minimum JDK version
>>
>>Hi,
>>
>>the interesting thing here is that we actually compile the code with -
>>source and -target=1.6 in these branches [1][2]. However, the javac still
>>uses the rt.jar coming from the current JDK and it does contain the
>>java.nio package. It seems that the only way to check the API usage
>>correctness is to switch to JDK 1.6.
>>
>>Or maybe there’s some way to validate whether the used packages matches
>>selected JDK version (eg. via some plugin reading the @since javadocs in
>>API classes)?
>>
>>Regards,
>>Tomek
>>
>>[1] https://github.com/apache/jackrabbit-oak/blob/1.4/oak-
>>parent/pom.xml#L97
>>[2] https://github.com/apache/jackrabbit-oak/blob/1.2/oak-
>>parent/pom.xml#L95
>>
>>
>>--
>>Tomek Rękawek | Adobe Research | www.adobe.com
>>reka...@adobe.com
>>
>>> On 12 Sep 2016, at 11:42, Davide Giannella  wrote:
>>>
>>> Hello team,
>>>
>>> following the recent mishap about JDK version and releases highlighted
>>> two main issues:
>>>
>>> cannot find jenkins for anything that is not 1.6
>>>
>>> we should enforce the build to build with the minimum required JDK.
>>>
>>> Now for the second point, this is easily achievable. What we have to
>>> decide is whether we want this enforcement done on all the builds, or
>>> only during releases build and checks.
>>>
>>> I'm for having it enforced on all the builds.
>>>
>>> Thoughts?
>>>
>>> Davide
>>>
>>>
>

RE: Minimum JDK version

[Stefan Seifert]

in sling we use the animal sniffer plugin for exactly this purpose [1].
it checks that the compiled codes only uses signatures available in the 
configured jdk.

stefan

[1] http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/

>-Original Message-
>From: Tomek Rekawek [mailto:reka...@adobe.com]
>Sent: Monday, September 12, 2016 1:06 PM
>To: oak-dev@jackrabbit.apache.org
>Subject: Re: Minimum JDK version
>
>Hi,
>
>the interesting thing here is that we actually compile the code with -
>source and -target=1.6 in these branches [1][2]. However, the javac still
>uses the rt.jar coming from the current JDK and it does contain the
>java.nio package. It seems that the only way to check the API usage
>correctness is to switch to JDK 1.6.
>
>Or maybe there’s some way to validate whether the used packages matches
>selected JDK version (eg. via some plugin reading the @since javadocs in
>API classes)?
>
>Regards,
>Tomek
>
>[1] https://github.com/apache/jackrabbit-oak/blob/1.4/oak-
>parent/pom.xml#L97
>[2] https://github.com/apache/jackrabbit-oak/blob/1.2/oak-
>parent/pom.xml#L95
>
>
>--
>Tomek Rękawek | Adobe Research | www.adobe.com
>reka...@adobe.com
>
>> On 12 Sep 2016, at 11:42, Davide Giannella  wrote:
>>
>> Hello team,
>>
>> following the recent mishap about JDK version and releases highlighted
>> two main issues:
>>
>> cannot find jenkins for anything that is not 1.6
>>
>> we should enforce the build to build with the minimum required JDK.
>>
>> Now for the second point, this is easily achievable. What we have to
>> decide is whether we want this enforcement done on all the builds, or
>> only during releases build and checks.
>>
>> I'm for having it enforced on all the builds.
>>
>> Thoughts?
>>
>> Davide
>>
>>

Re: Minimum JDK version

[Tomek Rekawek]

Hi,

the interesting thing here is that we actually compile the code with -source 
and -target=1.6 in these branches [1][2]. However, the javac still uses the 
rt.jar coming from the current JDK and it does contain the java.nio package. It 
seems that the only way to check the API usage correctness is to switch to JDK 
1.6.

Or maybe there’s some way to validate whether the used packages matches 
selected JDK version (eg. via some plugin reading the @since javadocs in API 
classes)?

Regards,
Tomek

[1] https://github.com/apache/jackrabbit-oak/blob/1.4/oak-parent/pom.xml#L97
[2] https://github.com/apache/jackrabbit-oak/blob/1.2/oak-parent/pom.xml#L95


-- 
Tomek Rękawek | Adobe Research | www.adobe.com
reka...@adobe.com

> On 12 Sep 2016, at 11:42, Davide Giannella  wrote:
> 
> Hello team,
> 
> following the recent mishap about JDK version and releases highlighted
> two main issues:
> 
> cannot find jenkins for anything that is not 1.6
> 
> we should enforce the build to build with the minimum required JDK.
> 
> Now for the second point, this is easily achievable. What we have to
> decide is whether we want this enforcement done on all the builds, or
> only during releases build and checks.
> 
> I'm for having it enforced on all the builds.
> 
> Thoughts?
> 
> Davide
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Minimum JDK version

[Julian Reschke]

On 2016-09-12 11:42, Davide Giannella wrote:

Hello team,

following the recent mishap about JDK version and releases highlighted
two main issues:

cannot find jenkins for anything that is not 1.6

we should enforce the build to build with the minimum required JDK.

Now for the second point, this is easily achievable. What we have to
decide is whether we want this enforcement done on all the builds, or
only during releases build and checks.

I'm for having it enforced on all the builds.

Thoughts?


+1, the build should fail as early as possible (that is, before we 
actually commit the bad code).


Best regards, Julian

Re: CommitHooks as OSGi Components.

[Ian Boston]

On 12 September 2016 at 10:45, Chetan Mehrotra 
wrote:

> On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston  wrote:
> > but if the information that connect a sessionID/userID to the
> > paths that are modified is available through some other route, I might be
> > able to use something else.
>
> A regular Observer should work for that case. Just register an
> instance with service registry and it would be picked up and for non
> external event CommitInfo would be present
>

Perfect,
thanks.
I should have spotted that.
Best Regards
Ian


>
> Chetan Mehrotra
>

Re: CommitHooks as OSGi Components.

[Chetan Mehrotra]

On Mon, Sep 12, 2016 at 3:12 PM, Ian Boston  wrote:
> but if the information that connect a sessionID/userID to the
> paths that are modified is available through some other route, I might be
> able to use something else.

A regular Observer should work for that case. Just register an
instance with service registry and it would be picked up and for non
external event CommitInfo would be present

Chetan Mehrotra

Re: CommitHooks as OSGi Components.

[Ian Boston]

Hi,


On 12 September 2016 at 09:43, Chetan Mehrotra 
wrote:

> On Mon, Sep 12, 2016 at 2:08 PM, Ian Boston  wrote:
> > Unfortunately the IndexProvider route doesn't appear give me the
> > information I am after (CommitInfo).
>
> Any details around intended usage? CommitInfo is now exposed via
> OAK-4642 to IndexEditorProvider
>

I would like it to work with older versions of oak pre 1.5.8 or 1.6

The use case is to capture commit info and pump it into a dataset for
visualisation along with other activity information. CommitInfo seems to be
what I need, but if the information that connect a sessionID/userID to the
paths that are modified is available through some other route, I might be
able to use something else.

Best Regards
Ian



>
> Chetan Mehrotra
>

Minimum JDK version

[Davide Giannella]

Hello team,

following the recent mishap about JDK version and releases highlighted
two main issues:

cannot find jenkins for anything that is not 1.6

we should enforce the build to build with the minimum required JDK.

Now for the second point, this is easily achievable. What we have to
decide is whether we want this enforcement done on all the builds, or
only during releases build and checks.

I'm for having it enforced on all the builds.

Thoughts?

Davide

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.4.7 released

[Amit Jain]

On Mon, Sep 12, 2016 at 3:01 PM, Julian Reschke 
wrote:

> Unfortunately, 1.4 has the same problem as 1.2, it doesn't compile with
> JDK 6


Yes, now fixed with OAK-4790

Thanks
Amit

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.4.7 released

[Julian Reschke]

On 2016-09-12 11:04, Davide Giannella wrote:

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.4.7 The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:
...


Unfortunately, 1.4 has the same problem as 1.2, it doesn't compile with 
JDK 6. (Sorry for not noticing).


Best regards, Julian

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.19

[Julian Reschke]

On 2016-09-12 10:09, Marcel Reutegger wrote:

On 12/09/16 08:36, Amit Jain wrote:

Please vote on releasing this package as Apache Jackrabbit Oak 1.2.19.
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 Do not release this package because...

...sources cannot be built with Java 6.

In my view the dependency to a newer Java version was introduced
accidentally and not on purpose. We increased it to Java 7 only
on trunk. See OAK-4189.

Regards
 Marcel


Unfortunately, the 1.4 branch (just released) has the same problem.

Best regards, Julian

[ANNOUNCE] Apache Jackrabbit Oak 1.4.7 released

[Davide Giannella]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit Oak 1.4.7 The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:


Release Notes -- Apache Jackrabbit Oak -- Version 1.4.7

Introduction


Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content applications.

Jackrabbit Oak 1.4.7 is a patch release that contains fixes and
improvements over Oak 1.4. Jackrabbit Oak 1.4.x releases are
considered stable and targeted for production use.

The Oak effort is a part of the Apache Jackrabbit project.
Apache Jackrabbit is a project of the Apache Software Foundation.

Changes in Oak 1.4.7
-

Bug

[OAK-4153] - segment's compareAgainstBaseState wont call
childNodeDeleted when deleting last and adding n nodes
[OAK-4219] - ExternalLoginModuleTestBase doesn't remove synced
User/Group accounts
[OAK-4224] - DefaultSyncContext.sync(ExternalIdentity) should
verify IDP
[OAK-4231] - DefaultSyncContext creates Value of type String for
Binary|Inputstream Object
[OAK-4267] - SyncedIdentity for foreign authorizable always has
isGroup set to false
[OAK-4302] - DefaultSyncContextTest contains duplicate test
[OAK-4431] - Index path property should be considered optional for
copy on read logic
[OAK-4448] - Test failures that rely on expiration time to
experience a re-sync.
[OAK-4600] - In case of branch commits, nodeChildrenCache gets
entries for branch revision without "br" prefix
[OAK-4658] - Outer join: name(b) and localname(b) can throw a NPE
[OAK-4675] - SNFE thrown while testing FileStore.cleanup() running
concurrently with writes
[OAK-4676] - Index definition on nt:base with analyzed property
incorrectly matches query with different property
[OAK-4679] - Backport OAK-4119, OAK-4101, OAK-4087 and OAK-4344
[OAK-4682] - ConcurrentModificationException in
JournalEntry.TreeNode
[OAK-4684] - RepositorySidegrade should also run commit hooks as
they are run in upgrade

Improvement

[OAK-3563] - Improve DefaultSyncContext
[OAK-4001] - ExternalLoginModule: Make max sync attempts
configurable
[OAK-4005] - LdapIdentityProvider.getEntries() is prone to OOME.
[OAK-4087] - Replace Sync of configured AutoMembership by Dynamic
Principal Generation
[OAK-4119] - Improvements Take 1
[OAK-4152] - Expose the index path to IndexEditor
[OAK-4320] - Use the cache tracker in the RDB Document Store
[OAK-4347] - Use the indexPath from hidden property instead of
taking this as input as part of index config
[OAK-4384] - Benchmarks: add support 'automembership' config
option
[OAK-4385] - Benchmarks: proper init of
ExternalPrincipalConfiguration with dynamicMembership
[OAK-4516] - Configurable option to lucene index defs to index
original (unanalyzed value as well)
[OAK-4585] - Text extraction: runtime status monitoring
[OAK-4623] - Log more information when null DocumentNodeState is
read for a child while fetching children
[OAK-4677] - stop oak-core bundle only transiently on lease
failure
[OAK-4678] - Backport OAK-4344 and OAK-4005

New Feature

[OAK-4101] - Consider separate external (group) principal
management

Task

[OAK-3211] - Document External Identity Management
[OAK-4364] - Initial Benchmarks for oak-auth-external
[OAK-4671] - Update 1.4 to JR 2.12.3
[OAK-4743] - Update Oak 1.2 and Oak 1.4 to Jackrabbit 2.12.4

Test

[OAK-4226] - Improve testing of DefaultSyncContext
[OAK-4248] - More tests for the exposed 'basic' package
[OAK-4382] - Test failure in
ExternalGroupPrincipalProviderTest.testFindPrincipalsByHintTypeGroup

In addition to the above-mentioned changes, this release contains
all changes included up to the Apache Jackrabbit Oak 1.4.x release.

For more detailed information about all the changes in this and other
Oak releases, please see the Oak issue tracker at

  https://issues.apache.org/jira/browse/OAK

Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by SHA1 and MD5 checksums and a PGP
signature that you can use to verify the authenticity of your download.
The public key used for the PGP signature can be found at
http://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit Oak
---

Jackrabbit Oak is a scalable, high-performance hierarchical content
repository designed for use as the foundation of modern world-class
web sites and other demanding content 

[RESULT][VOTE] Release Apache Jackrabbit Oak 1.4.7

[Davide Giannella]

Hello Team,

the vote passes as follows:

+1 Davide Giannella
+1 Dominique Jaeggi
+1 Julian Reschke

Thanks for voting. I'll push the release out.

-- Davide

Re: [observation] more options in JackrabbitEventFilter

[Stefan Egli]

Hi Davide,

On 08/09/16 14:24, "Davide Giannella"  wrote:

>On 07/09/2016 14:04, Michael Dürig wrote:
>> No not open them. But make their functionality available through an
>> API. Since JCR is dead (hint hint) we probably have to come up with an
>> ad-hoc API here.
>FWIW, I'm for exposing this aspect as Oak API.

Would be fine for me, however, how would you do that?

IIUC then EventListeners are registered via either JCR's
ObservationManager or Jackrabbit's extension at [0]. If you want to do
this in Oak (ie not in Jackrabbit) then would you extend Oak's
Observationmanager ([1]) directly?


Cheers,
Stefan
--
[0] - 
https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-api/src/main/jav
a/org/apache/jackrabbit/api/observation/JackrabbitObservationManager.java#L
26
[1] - 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/o
rg/apache/jackrabbit/oak/jcr/observation/ObservationManagerImpl.java

>
>Then in Oak we implement few Filters for the already existing mechanism,
>so that the jcr layer can map the JCR API as Oak api.
>
>An application that needs to have complex filtering, will have to
>leverage the Oak API.
>
>Don't know whether it will be possible for an application to leverage
>*both* JCR and Oak APIs but I'm sure there are ways around it.
>
>Cheers
>Davide
>
>

Re: CommitHooks as OSGi Components.

[Chetan Mehrotra]

On Mon, Sep 12, 2016 at 2:08 PM, Ian Boston  wrote:
> Unfortunately the IndexProvider route doesn't appear give me the
> information I am after (CommitInfo).

Any details around intended usage? CommitInfo is now exposed via
OAK-4642 to IndexEditorProvider

Chetan Mehrotra

Re: CommitHooks as OSGi Components.

[Ian Boston]

Hi,
Thank you for the pointers.
Unfortunately the IndexProvider route doesn't appear give me the
information I am after (CommitInfo).
Since I need this to work in an independent bundle patching the repository
manager isn't an option.
I am currently looking to see if there are any other services exposed that
might give me a route in.
Best Regards
Ian

On 12 September 2016 at 08:38, Michael Dürig  wrote:

>
> Hi,
>
> No it isn't. Commit hooks haven't been designed for this type of
> dynamicity and generality. Exposing them at this layer has been considered
> way to dangerous and a breach of modularity.
>
> What has been done in the past for use cases requiring commit hook
> functionality on one hand and some part of dynamicity on the other, was to
> to specialise the use case. Index editors are one example here.
>
> Michael
>
>
> On 9.9.16 6:04 , Ian Boston wrote:
>
>> Hi,
>> Is it possible write a CommitHook as an OSGI Component/Service and for Oak
>> to pick it up ?
>> The Component starts and gets registered as a service, but Oak doesn't
>> appear to pick it up.
>> If its not possible to add a CommitHook in this way, what is the best way
>> of doing it from outside the oak-core bundle ?
>> Best Regards
>> Ian
>>
>>

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.19

[Amit Jain]

Hi,

Due to the compile errors with JDK 6 cancelling the release.

Thanks
Amit

On Mon, Sep 12, 2016 at 1:40 PM, Marcel Reutegger 
wrote:

> On 12/09/16 10:03, Amit Jain wrote:
>
>> On Mon, Sep 12, 2016 at 12:23 PM, Julian Reschke 
>> wrote:
>>
>> Isn't this still supposed to compile with JDK6?
>>>
>>
>> Probably yes. This was introduced with OAK-4454 in 1.2.18. So, what are
>> the
>> options now?
>>
>
> I'd say, cancel the release, fix the code and prepare a new 1.2.19 release.
>
> Regards
>  Marcel
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.19

[Marcel Reutegger]

On 12/09/16 10:03, Amit Jain wrote:

On Mon, Sep 12, 2016 at 12:23 PM, Julian Reschke 
wrote:


Isn't this still supposed to compile with JDK6?


Probably yes. This was introduced with OAK-4454 in 1.2.18. So, what are the
options now?


I'd say, cancel the release, fix the code and prepare a new 1.2.19 release.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.19

[Marcel Reutegger]

On 12/09/16 08:36, Amit Jain wrote:

Please vote on releasing this package as Apache Jackrabbit Oak 1.2.19.
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 Do not release this package because...

...sources cannot be built with Java 6.

In my view the dependency to a newer Java version was introduced
accidentally and not on purpose. We increased it to Java 7 only
on trunk. See OAK-4189.

Regards
 Marcel

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.19

[Amit Jain]

On Mon, Sep 12, 2016 at 12:23 PM, Julian Reschke 
wrote:

> Isn't this still supposed to compile with JDK6?


Probably yes. This was introduced with OAK-4454 in 1.2.18. So, what are the
options now?

Thanks
Amit

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.19

[Dominique Jaeggi]

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

Re: CommitHooks as OSGi Components.

[Michael Dürig]

Hi,

No it isn't. Commit hooks haven't been designed for this type of 
dynamicity and generality. Exposing them at this layer has been 
considered way to dangerous and a breach of modularity.


What has been done in the past for use cases requiring commit hook 
functionality on one hand and some part of dynamicity on the other, was 
to to specialise the use case. Index editors are one example here.


Michael

On 9.9.16 6:04 , Ian Boston wrote:

Hi,
Is it possible write a CommitHook as an OSGI Component/Service and for Oak
to pick it up ?
The Component starts and gets registered as a service, but Oak doesn't
appear to pick it up.
If its not possible to add a CommitHook in this way, what is the best way
of doing it from outside the oak-core bundle ?
Best Regards
Ian

Re: CommitHooks as OSGi Components.

[Tomek Rekawek]

Hi Ian,

> On 09 Sep 2016, at 18:04, Ian Boston  wrote:
> 
> Hi,
> Is it possible write a CommitHook as an OSGI Component/Service and for Oak
> to pick it up ?
> The Component starts and gets registered as a service, but Oak doesn't
> appear to pick it up.

The standard RepositoryManager[1] (responsible for setting-up the repo) allows 
to register EditorProvider, IndexEditorProvider and IndexProvider via OSGi. If 
you use a Sling-based setup, then the repository is created by 
OakSlingRepositoryManager[2] and it’s only possible to register index-related 
services.

> If its not possible to add a CommitHook in this way, what is the best way
> of doing it from outside the oak-core bundle ?

I’m afraid they can’t be added dynamically, so you need to modify the 
*RepositoryManager class and add an appropriate .with() invocation.

Regards,
Tomek

[1] 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/osgi/RepositoryManager.java
[2] 
https://github.com/apache/sling/blob/trunk/bundles/jcr/oak-server/src/main/java/org/apache/sling/jcr/oak/server/internal/OakSlingRepositoryManager.java

-- 
Tomek Rękawek | Adobe Research | www.adobe.com
reka...@adobe.com



smime.p7s
Description: S/MIME cryptographic signature

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.19

[Julian Reschke]

On 2016-09-12 08:36, Amit Jain wrote:

...


Isn't this still supposed to compile with JDK6?

Asking because:


[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) 
on project oak-commons: Compilation failure: Compilation failure:
[ERROR] 
C:\projects\apache\jackrabbit\jackrabbit-dev\target\jackrabbit-oak-1.2.19\zip\jackrabbit-oak-1.2.19\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\FileIOUtils.java:[37,30]
 cannot find symbol
[ERROR] symbol  : class StandardCharsets
[ERROR] location: package java.nio.charset
[ERROR] 
C:\projects\apache\jackrabbit\jackrabbit-dev\target\jackrabbit-oak-1.2.19\zip\jackrabbit-oak-1.2.19\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\FileIOUtils.java:[37,0]
 static import only from classes and interfaces
[ERROR] 
C:\projects\apache\jackrabbit\jackrabbit-dev\target\jackrabbit-oak-1.2.19\zip\jackrabbit-oak-1.2.19\oak-commons\src\main\java\org\apache\jackrabbit\oak\commons\FileIOUtils.java:[79,46]
 cannot find symbol
[ERROR] symbol  : variable UTF_8
[ERROR] location: class org.apache.jackrabbit.oak.commons.FileIOUtils
[ERROR] -> [Help 1]


Best regards, Julian

[VOTE] Release Apache Jackrabbit Oak 1.2.19

[Amit Jain]

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

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

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


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

The SHA1 checksum of the archive is
b65a77717bef5163e9c0fbbce78c9e1108c02f83.

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.2.19
b65a77717bef5163e9c0fbbce78c9e1108c02f83

Please vote on releasing this package as Apache Jackrabbit Oak 1.2.19.
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.2.19
[ ] -1 Do not release this package because...

My vote is +1.

Thanks
Amit