[jira] [Created] (JCR-4062) Path / data disappearing

2016-11-24 Thread Ravindra Kirpane (JIRA) 
Ravindra Kirpane created JCR-4062:
-

 Summary: Path / data disappearing
 Key: JCR-4062
 URL: https://issues.apache.org/jira/browse/JCR-4062
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: clustering, core, jackrabbit-data
Affects Versions: 2.13.4
 Environment: Clustered environment in Production with Java application
Reporter: Ravindra Kirpane


Looking for SME with deep knowledge about JCR and its configuration.
We have 5 Nodes setup in our project with clustering having Repository set for 
each node with single MySQL database.
The index / repository size is gone upto about 70GB.
Recently we had issues with lucene index files not synching.
Which we are not able to solve yet and we resorted to make an entry in table 
and use that to search for a node.
Recently we have encountered that complete information / data under a path is 
getting lost suddenly. It is happening with parent paths that were created 
about a year back.
Parent path are seen but the child path when created are disappearing without 
any logs. (NO LOGS)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4062) Path / data disappearing

2016-11-24 Thread Ravindra Kirpane (JIRA) 

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

Ravindra Kirpane updated JCR-4062:
--
Description: 
Looking for SME with deep knowledge or solution about JCR and its configuration.
We have 5 Nodes setup in our project with clustering having Repository set for 
each node with single MySQL database.
The index / repository size is gone upto about 70GB.
Recently we had issues with lucene index files not synching.
Which we are not able to solve yet and we resorted to make an entry in table 
and use that to search for a node.
Recently we have encountered that complete information / data under a path is 
getting lost suddenly. It is happening with parent paths that were created 
about a year back.
Parent path are seen but the child path when created are disappearing without 
any logs. (NO LOGS)

  was:
Looking for SME with deep knowledge about JCR and its configuration.
We have 5 Nodes setup in our project with clustering having Repository set for 
each node with single MySQL database.
The index / repository size is gone upto about 70GB.
Recently we had issues with lucene index files not synching.
Which we are not able to solve yet and we resorted to make an entry in table 
and use that to search for a node.
Recently we have encountered that complete information / data under a path is 
getting lost suddenly. It is happening with parent paths that were created 
about a year back.
Parent path are seen but the child path when created are disappearing without 
any logs. (NO LOGS)


> Path / data disappearing
> 
>
> Key: JCR-4062
> URL: https://issues.apache.org/jira/browse/JCR-4062
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: clustering, core, jackrabbit-data
>Affects Versions: 2.13.4
> Environment: Clustered environment in Production with Java application
>Reporter: Ravindra Kirpane
>
> Looking for SME with deep knowledge or solution about JCR and its 
> configuration.
> We have 5 Nodes setup in our project with clustering having Repository set 
> for each node with single MySQL database.
> The index / repository size is gone upto about 70GB.
> Recently we had issues with lucene index files not synching.
> Which we are not able to solve yet and we resorted to make an entry in table 
> and use that to search for a node.
> Recently we have encountered that complete information / data under a path is 
> getting lost suddenly. It is happening with parent paths that were created 
> about a year back.
> Parent path are seen but the child path when created are disappearing without 
> any logs. (NO LOGS)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCR-4061) JCR expertise required

2016-11-24 Thread Ravindra Kirpane (JIRA) 
Ravindra Kirpane created JCR-4061:
-

 Summary: JCR expertise required
 Key: JCR-4061
 URL: https://issues.apache.org/jira/browse/JCR-4061
 Project: Jackrabbit Content Repository
  Issue Type: Wish
  Components: clustering
Affects Versions: 2.13.4
 Environment: JCR Cluster Node
Reporter: Ravindra Kirpane
Priority: Blocker


Looking for SME with deep knowledge about JCR and its configuration.

We have 5 Nodes setup in our project with clustering having Repository set for 
each node with single MySQL database.

The index / repository size is gone upto about 70GB.

Recently we had issues with lucene index files not synching. 

Which we are not able to solve yet and we resorted to make an entry in table 
and use that to search for a node. 

Recently we have encountered that complete information / data under a path is 
getting lost suddenly. It is happening with parent paths that were created 
about a year back. 

Parent path are seen but the child path when created are disappearing without 
any logs. (NO LOGS)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 1300 - Still Failing

2016-11-24 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1300)

Status: Still Failing

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

Changes:
[amitj] OAK-5146: S3 getOrCreateReferenceKey() should provide a default

[amitj] OAK-4979: @trivial javadoc fixes

[stefanegli] OAK-5151 : tests added for ChangeSet overflowing and its handling 
in

[tomekr] OAK-5154: Checkpoints should only be migrated if no custom paths are

[mreutegg] OAK-5155: Remove oak.documentMK.cacheConcurrency system property

[mreutegg] OAK-5132: Limit diff cache entries in size

[frm] OAK-5135 - Release the lock if the journal file is closed

[tomekr] OAK-5157: Source repository should be opened in read-only mode for

[angela] minor improvement: security documentation

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[chetanm] OAK-4898 - Allow for external changes to have a CommitInfo attached

[frm] OAK-4561 - Remove dependency on Apache Commons Math

[mduerig] OAK-5161: Improve logging of compaction cycles Add more information to

[angela] minor improvement: security documentation

[angela] javadoc: remove todo without jira  reference

 

Test results:
8 tests failed.
FAILED:  
org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest.org.apache.jackrabbit.oak.security.authentication.ldap.LdapDefaultLoginModuleTest

Error Message:
ERR_171 Failed to bind an LDAP service (1,024) to the service registry.

Stack Trace:
org.apache.directory.api.ldap.model.exception.LdapConfigurationException: 
ERR_171 Failed to bind an LDAP service (1,024) to the service registry.
at 
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:695)
at 
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:547)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.setUp(AbstractServer.java:229)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:33)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at

[Oak origin/1.4] Apache Jackrabbit Oak matrix - Build # 1299 - Still Failing

2016-11-24 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build 
#1299)

Status: Still Failing

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

Changes:
[mreutegg] OAK-5150: Log stats for JournalDiffLoader

[mreutegg] OAK-5155: Remove oak.documentMK.cacheConcurrency system property

[mreutegg] OAK-5132: Limit diff cache entries in size

 

Test results:
7 tests failed.
FAILED:  
org.apache.jackrabbit.oak.security.authentication.ldap.DefaultLdapLoginModuleTest.org.apache.jackrabbit.oak.security.authentication.ldap.DefaultLdapLoginModuleTest

Error Message:
ERR_171 Failed to bind an LDAP service (1,024) to the service registry.

Stack Trace:
org.apache.directory.api.ldap.model.exception.LdapConfigurationException: 
ERR_171 Failed to bind an LDAP service (1,024) to the service registry.
at 
org.apache.directory.server.ldap.LdapServer.startNetwork(LdapServer.java:695)
at 
org.apache.directory.server.ldap.LdapServer.start(LdapServer.java:547)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.AbstractServer.setUp(AbstractServer.java:232)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.InternalLdapServer.setUp(InternalLdapServer.java:31)
at 
org.apache.jackrabbit.oak.security.authentication.ldap.LdapLoginTestBase.beforeClass(LdapLoginTestBase.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at 
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at 
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:463)
at sun.nio.ch.Net.bind(Net.java:455)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:198)
at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.open(NioSocketAcceptor.java:51)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.registerHandles(AbstractPollingIoAcceptor.java:547)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor.access$400(AbstractPollingIoAcceptor.java:68)
at 
org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.java:422)
at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)


FAILED:  
org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest.testAuthenticateMissing

Error Message:
ERR_171 Failed to bind an LDAP service (1,024) to the service registry.

Stack Trace:
org.apache.directory.api.ldap.model.exception.LdapConfigurationException: 
ERR_171 Failed to bind an LDAP service (1,024) to the service registry.
at

Re: Frequent failures in standby test

2016-11-24 Thread Chetan Mehrotra 
Per https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1298/
the test again failed but mostly on Jdk 1.7. The test on Jdk 1.8 looks
like passed.
Chetan Mehrotra


On Tue, Nov 22, 2016 at 12:48 PM, Chetan Mehrotra
 wrote:
> They are from oak-segment-tar. See
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1295/#showFailuresLink
> Chetan Mehrotra
>
>
> On Tue, Nov 22, 2016 at 12:42 PM, Francesco Mari
>  wrote:
>> Are those from oak-tarmk-standby or oak-segment-tar?
>>
>> 2016-11-22 6:11 GMT+01:00 Chetan Mehrotra :
>>> Hi Team,
>>>
>>> Since last 4-6 builds I am seeing a recurring failure of few test in
>>> standby module
>>>
>>> * FailoverIPRangeIT
>>> * ExternalPrivateStoreIT
>>> * StandbyTestIT
>>>
>>> Probably something to be looked into
>>>
>>> Chetan Mehrotra

Re: oak-lucene shaded

2016-11-24 Thread Chetan Mehrotra 
Hi Torgeir,

We would not be able shade Lucene classes as they are exported and
meant to be used by certain SPI implementations. So as of now there is
no solution for using a different Lucene version in non OSGi world


Chetan Mehrotra


On Wed, Nov 23, 2016 at 7:15 PM, Torgeir Veimo  wrote:
> Second version, this pom file can be put in a separate directly as a self
> contained maven artifact and includes oak-lucene remotely.
>
> 
>
> 
>
> http://maven.apache.org/POM/4.0.0; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd
> ">
> 4.0.0
>
> no.karriere
> 0.1-SNAPSHOT
> oak-lucene-shaded
> Oak Lucene (shaded)
> Oak Lucene integration subproject
>
> 
> 1.5
> 4.7.1
> 1.4.6
> 
>
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-source-plugin
> 3.0.1
> 
> 
> generate-sources-for-shade-plugin
> package
> 
> jar-no-fork
> 
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-shade-plugin
> 3.0.0-SNAPSHOT
> 
> 
> package
> 
> shade
> 
> 
>
> 
>
> false
> true
> true
> 
>  implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
> 
> 
> 
> org.apache.lucene
>
> org.shaded.apache.lucene
> 
> 
> org.tartarus.snowball
>
> org.shaded.tartarus.snowball
> 
> 
> 
> 
>
> org.apache.jackrabbit:oak-core
>
> org.apache.jackrabbit:oak-commons
>
> org.apache.jackrabbit:oak-blob
>
> com.google.guava:guava
>
> commons-codec:commons-codec
> commons-io:commons-io
> javax.jcr:jcr
>
> org.apache.jackrabbit:jackrabbit-api
>
> org.apache.jackrabbit:jackrabbit-jcr-commons
>
> org.apache.tika:tika-core
> org.slf4j:slf4j-api
> 
> 
> 
> 
> 
> 
> 
> 
>
> 
> 
> org.apache.jackrabbit
> oak-core
> ${oak.version}
> 
> 
> org.apache.jackrabbit
> oak-lucene
> ${oak.version}
> 
> 
> org.apache.tika
> tika-core
> ${tika.version}
> 
>
> 
> 
> org.apache.lucene
> lucene-core
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-analyzers-common
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-queryparser
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-queries
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-suggest
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-highlighter
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-memory
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-misc
> ${lucene.version}
> 
> 
> org.apache.lucene
> lucene-facet
> ${lucene.version}
> 
>
> 
> org.apache.tika
> tika-parsers
> ${tika.version}
> test
> 
> 
> commons-logging
> commons-logging
> 
> 
> 
> 
>
> 
> 
> org.apache
> Apache snapshots
> http://repository.apache.org/content/repositories/snapshots
> 
> 
> true
> 
> 
> 
> 
>
>
> On 15 November 2016 at 11:12, Torgeir Veimo  wrote:
>
>> I'm in need of running oak in a

[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager

2016-11-24 Thread angela (JIRA) 

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

angela commented on JCR-4050:
-

[~bornemannjs], i see your point. on the other hand, the creation of the 
pw-hash should be consideren an implementation detail of a given user 
management implementation and i don't see too much benefit of having such an 
API call without the ability to generate the hash. in other words: a caller of 
that API would only be able to create a pw-hash by relying on implementation 
details, which IMO is looking for troubles. 
but since you are mentioning AEM Package Manager: is this related to Jackrabbit 
FileVault project? afaik that project within the Jackrabbit family provides 
means to package and install repository content including users. If that was 
anyhow related, I would recommend to provide patches there if you find room for 
improvement in terms of performance and scalability. 

>  Allow creation of users with existing password hashes in UserManager
> -
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core, security
>Reporter: Jeffrey Bornemann
>Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes 
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting 
> passwords from existing users; we have no public API facing way to create 
> users with existing password hashes. We currently have to resort to using 
> reflection, grabbing internal tree objects, and a bunch of nastiness that we 
> would love to avoid with this change.
> Other consumers may also find this useful. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4050) Allow creation of users with existing password hashes in UserManager

2016-11-24 Thread angela (JIRA) 

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

angela commented on JCR-4050:
-

[~olli], i have to say that i am pretty surprised to see the repo-init tool to 
allow for creation of regular users. i distinctly remember the initial idea was 
to provide a tool to create service users and that me and other security 
engineers strongly suggested to not expand that to regular users. i am not sure 
I understand what would be the use case for creating regular users during the 
repo init. and apart from that, if users were to be pre-created based on a 
configuration that can be share by different installations, i would strongly 
recommend to create them without password. writing the pw to the provision 
model really sounds like a very bad idea.

/cc [~bdelacretaz]

>  Allow creation of users with existing password hashes in UserManager
> -
>
> Key: JCR-4050
> URL: https://issues.apache.org/jira/browse/JCR-4050
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-api, jackrabbit-core, security
>Reporter: Jeffrey Bornemann
>Priority: Minor
>
> We utilize the UserManager API within Grabbit for syncing authorizable nodes 
> between servers.
> Unfortunately, when it comes to syncing users, and specifically setting 
> passwords from existing users; we have no public API facing way to create 
> users with existing password hashes. We currently have to resort to using 
> reflection, grabbing internal tree objects, and a bunch of nastiness that we 
> would love to avoid with this change.
> Other consumers may also find this useful. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

2016-11-24 Thread Konrad Windszus (JIRA) 

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

Konrad Windszus edited comment on JCR-4060 at 11/24/16 2:21 PM:


The change was done in bnd 1.37.0 (https://github.com/bndtools/bnd/issues/27). 
maven-bundle-plugin 3.0.1 leverages bnd in version 3.0.0. The previous version 
of maven-bundle-plugin 2.3.4 still leveraged bnd in version 1.15.0 
(https://mvnrepository.com/artifact/org.apache.felix/maven-bundle-plugin/2.3.4)


was (Author: kwin):
The change was done in bnd 1.37.0 (https://github.com/bndtools/bnd/issues/27). 
maven-bundle-plugin 3.0.1 leverages bnd in version 3.0.0.

> unintended export versions due to changed defaults in maven bundle plugin
> -
>
> Key: JCR-4060
> URL: https://issues.apache.org/jira/browse/JCR-4060
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.12.5, 2.13.4
>Reporter: Julian Reschke
>Priority: Blocker
> Fix For: 2.14
>
>
> It appears that the maven bundle plugin change for JCR-3937 has caused 
> default export version numbers to be assigned where before we hadn't any.
> For instance, in jackrabbit-api, the package "o.a.j.api" has a 
> package-info.java setting the version to 2.4, and this is what get's exported.
> However, o.a.j.api.query does not have a package-info, and now gets exported 
> with a version number of 2.13.5, whereas previously it didn't get any version 
> number.
> a) Does anybody know whether this change in behavior of the bundle plugin is 
> documented anywhere?
> b) Do we need to fix something here, or are automatically assigned version 
> numbers indeed ok? If we need to do something, what is the correct fix? 
> Freeze the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

2016-11-24 Thread Konrad Windszus (JIRA) 

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

Konrad Windszus commented on JCR-4060:
--

The change was done in bnd 1.37.0 (https://github.com/bndtools/bnd/issues/27). 
maven-bundle-plugin 3.0.1 leverages bnd in version 3.0.0.

> unintended export versions due to changed defaults in maven bundle plugin
> -
>
> Key: JCR-4060
> URL: https://issues.apache.org/jira/browse/JCR-4060
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.12.5, 2.13.4
>Reporter: Julian Reschke
>Priority: Blocker
> Fix For: 2.14
>
>
> It appears that the maven bundle plugin change for JCR-3937 has caused 
> default export version numbers to be assigned where before we hadn't any.
> For instance, in jackrabbit-api, the package "o.a.j.api" has a 
> package-info.java setting the version to 2.4, and this is what get's exported.
> However, o.a.j.api.query does not have a package-info, and now gets exported 
> with a version number of 2.13.5, whereas previously it didn't get any version 
> number.
> a) Does anybody know whether this change in behavior of the bundle plugin is 
> documented anywhere?
> b) Do we need to fix something here, or are automatically assigned version 
> numbers indeed ok? If we need to do something, what is the correct fix? 
> Freeze the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke updated JCR-4060:

Priority: Critical  (was: Major)

> unintended export versions due to changed defaults in maven bundle plugin
> -
>
> Key: JCR-4060
> URL: https://issues.apache.org/jira/browse/JCR-4060
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.12.5, 2.13.4
>Reporter: Julian Reschke
>Priority: Critical
> Fix For: 2.14
>
>
> It appears that the maven bundle plugin change for JCR-3937 has caused 
> default export version numbers to be assigned where before we hadn't any.
> For instance, in jackrabbit-api, the package "o.a.j.api" has a 
> package-info.java setting the version to 2.4, and this is what get's exported.
> However, o.a.j.api.query does not have a package-info, and now gets exported 
> with a version number of 2.13.5, whereas previously it didn't get any version 
> number.
> a) Does anybody know whether this change in behavior of the bundle plugin is 
> documented anywhere?
> b) Do we need to fix something here, or are automatically assigned version 
> numbers indeed ok? If we need to do something, what is the correct fix? 
> Freeze the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke updated JCR-4060:

Priority: Blocker  (was: Critical)

> unintended export versions due to changed defaults in maven bundle plugin
> -
>
> Key: JCR-4060
> URL: https://issues.apache.org/jira/browse/JCR-4060
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.12.5, 2.13.4
>Reporter: Julian Reschke
>Priority: Blocker
> Fix For: 2.14
>
>
> It appears that the maven bundle plugin change for JCR-3937 has caused 
> default export version numbers to be assigned where before we hadn't any.
> For instance, in jackrabbit-api, the package "o.a.j.api" has a 
> package-info.java setting the version to 2.4, and this is what get's exported.
> However, o.a.j.api.query does not have a package-info, and now gets exported 
> with a version number of 2.13.5, whereas previously it didn't get any version 
> number.
> a) Does anybody know whether this change in behavior of the bundle plugin is 
> documented anywhere?
> b) Do we need to fix something here, or are automatically assigned version 
> numbers indeed ok? If we need to do something, what is the correct fix? 
> Freeze the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke updated JCR-4060:

Fix Version/s: 2.14

> unintended export versions due to changed defaults in maven bundle plugin
> -
>
> Key: JCR-4060
> URL: https://issues.apache.org/jira/browse/JCR-4060
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Affects Versions: 2.12.5, 2.13.4
>Reporter: Julian Reschke
>Priority: Critical
> Fix For: 2.14
>
>
> It appears that the maven bundle plugin change for JCR-3937 has caused 
> default export version numbers to be assigned where before we hadn't any.
> For instance, in jackrabbit-api, the package "o.a.j.api" has a 
> package-info.java setting the version to 2.4, and this is what get's exported.
> However, o.a.j.api.query does not have a package-info, and now gets exported 
> with a version number of 2.13.5, whereas previously it didn't get any version 
> number.
> a) Does anybody know whether this change in behavior of the bundle plugin is 
> documented anywhere?
> b) Do we need to fix something here, or are automatically assigned version 
> numbers indeed ok? If we need to do something, what is the correct fix? 
> Freeze the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JCR-4060) unintended export versions due to changed defaults in maven bundle plugin

2016-11-24 Thread Julian Reschke (JIRA) 
Julian Reschke created JCR-4060:
---

 Summary: unintended export versions due to changed defaults in 
maven bundle plugin
 Key: JCR-4060
 URL: https://issues.apache.org/jira/browse/JCR-4060
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Affects Versions: 2.13.4, 2.12.5
Reporter: Julian Reschke


It appears that the maven bundle plugin change for JCR-3937 has caused default 
export version numbers to be assigned where before we hadn't any.

For instance, in jackrabbit-api, the package "o.a.j.api" has a 
package-info.java setting the version to 2.4, and this is what get's exported.

However, o.a.j.api.query does not have a package-info, and now gets exported 
with a version number of 2.13.5, whereas previously it didn't get any version 
number.

a) Does anybody know whether this change in behavior of the bundle plugin is 
documented anywhere?

b) Do we need to fix something here, or are automatically assigned version 
numbers indeed ok? If we need to do something, what is the correct fix? Freeze 
the version numbers at the currently assigned version?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCR-3937) jackrabbit-jcr-commons bundle incorrectly has google dependency in Export-Package uses clause

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke commented on JCR-3937:
-

trunk: [r1720093|http://svn.apache.org/r1720093]

> jackrabbit-jcr-commons bundle incorrectly has google dependency in 
> Export-Package uses clause
> -
>
> Key: JCR-3937
> URL: https://issues.apache.org/jira/browse/JCR-3937
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-jcr-commons
>Affects Versions: 2.11.3
>Reporter: David Bosschaert
>Assignee: Marcel Reutegger
> Fix For: 2.13.0, 2.12.0, 2.14
>
> Attachments: JCR-3937-2.patch, JCR-3937.patch
>
>
> jackrabbit-jcr-commons 2.11.3 has the following Export-Package line:
> {code}org.apache.jackrabbit.value;uses:="javax.jcr,org.apache.jackrabbit.util,com.google.common.collect";version="2.2.1"{code}
> The google uses is actually unnecessary and generated by a bug in the 
> maven-bundle-plugin. Using the latest version of that makes the google 
> transitive dependency go away.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-4059) avoid use of HttpClient3 URI class

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke edited comment on JCR-4059 at 11/24/16 9:06 AM:
---

trunk: [r1771078|http://svn.apache.org/r1771078]
2.12: [r1771079|http://svn.apache.org/r1771079]
2.10: [r1771080|http://svn.apache.org/r1771080]
2.8: [r1771091|http://svn.apache.org/r1771091]



was (Author: reschke):
trunk: [r1771078|http://svn.apache.org/r1771078]
2.12: [r1771079|http://svn.apache.org/r1771079]
2.10: [r1771080|http://svn.apache.org/r1771080]

> avoid use of HttpClient3 URI class
> --
>
> Key: JCR-4059
> URL: https://issues.apache.org/jira/browse/JCR-4059
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.10.5, 2.13.5, 2.8.4, 2.12.6, 2.14
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4059) avoid use of HttpClient3 URI class

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke updated JCR-4059:

Fix Version/s: 2.8.4

> avoid use of HttpClient3 URI class
> --
>
> Key: JCR-4059
> URL: https://issues.apache.org/jira/browse/JCR-4059
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.10.5, 2.13.5, 2.8.4, 2.12.6, 2.14
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCR-4059) avoid use of HttpClient3 URI class

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke updated JCR-4059:

Fix Version/s: 2.10.5

> avoid use of HttpClient3 URI class
> --
>
> Key: JCR-4059
> URL: https://issues.apache.org/jira/browse/JCR-4059
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.10.5, 2.13.5, 2.12.6, 2.14
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCR-4059) avoid use of HttpClient3 URI class

2016-11-24 Thread Julian Reschke (JIRA) 

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

Julian Reschke edited comment on JCR-4059 at 11/24/16 8:31 AM:
---

trunk: [r1771078|http://svn.apache.org/r1771078]
2.12: [r1771079|http://svn.apache.org/r1771079]
2.10: [r1771080|http://svn.apache.org/r1771080]


was (Author: reschke):
trunk: [r1771078|http://svn.apache.org/r1771078]
2.12: [r1771079|http://svn.apache.org/r1771079]

> avoid use of HttpClient3 URI class
> --
>
> Key: JCR-4059
> URL: https://issues.apache.org/jira/browse/JCR-4059
> Project: Jackrabbit Content Repository
>  Issue Type: Sub-task
>  Components: jackrabbit-spi2dav
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Fix For: 2.10.5, 2.13.5, 2.12.6, 2.14
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)