[jira] [Commented] (JCRSITE-44) Update contributor list

[Tae (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRSITE-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14975251#comment-14975251
 ] 

Tae commented on JCRSITE-44:


Stefan Egli is missing in the committer list. His Apache ID is stefanegli.

And also, the sorting is messed up:
ppakulski, ppiegaze, pmarx.

pmarz should come before ppakulski.

In the contributor list, Wolfgang Kurz is written with last name first: "Kurz 
Wolfgang".

> Update contributor list
> ---
>
> Key: JCRSITE-44
> URL: https://issues.apache.org/jira/browse/JCRSITE-44
> Project: Jackrabbit Site
>  Issue Type: Improvement
>Reporter: Tae
>
> The contributor list at:
> http://jackrabbit.apache.org/jcr/jackrbabit-team.html
> has some names which aren't accentuated (see the Jackrabbit contributors 
> section).
> The first column is unaccentuated, the second column is accentuated.
> Juan Jose Vazquez Delgado, Juan José Vázquez Delgado
> Martin Koci, Martin Kočí (it's a Czech name...)
> Please accentuate these names.



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

[VOTE] Release Apache Jackrabbit 2.11.2

[Davide Giannella]

A candidate for the Jackrabbit 2.11.2 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/2.11.2/

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

https://svn.apache.org/repos/asf/jackrabbit/tags/2.11.2/

The SHA1 checksum of the archive is
f95d38d7c69b799df0f68b49aa0162c16d3a7d9e.

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 2.11.2 f95d38d7c69b799df0f68b49aa0162c16d3a7d9e

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

[jira] [Created] (JCR-3925) JCR_SQL2 returns duplicated rows

[Kamil (JIRA)]

Kamil created JCR-3925:
--

 Summary: JCR_SQL2 returns duplicated rows
 Key: JCR-3925
 URL: https://issues.apache.org/jira/browse/JCR-3925
 Project: Jackrabbit Content Repository
  Issue Type: Bug
Reporter: Kamil


In my repository I have created few nodes: 
{noformat}
/foo
/bar
/bar/child 
/bar/child/grandchild
{noformat}

When I execute following code:
{noformat}
NodeIterator nodes = session.getRootNode().getNodes();
while(nodes.hasNext()){
Node n = nodes.nextNode();
System.out.println(String.format("%s: %s", n.getIdentifier(), n));
}
{noformat}

I get:
{noformat}
deadbeef-cafe-babe-cafe-babecafebabe: node /jcr:system
c0457b0d-2113-4d47-aa7c-d150bc74ce16: node /rep:security
ff67a591-52cb-4d37-b826-772fe6611b7e: node /bar
e2a097b1-62b6-4296-ab91-12b06e600ba3: node /rep:accesscontrol
76dbbae0-3b4d-43fc-b5d5-753792e2256b: node /foo
{noformat}

which is correct. But when I invoke:
{noformat}
QueryManager manager = session.getWorkspace().getQueryManager();

Query query = manager.createQuery("SELECT * FROM [nt:unstructured] AS n WHERE 
ISCHILDNODE('/')", Query.JCR_SQL2);

NodeIterator res = query.execute().getNodes();
while (res.hasNext()) {
Node n = res.nextNode();
System.out.println(String.format("%s: %s", n.getIdentifier(), n));
}
{noformat}

Nodes are duplicated!
{noformat}
76dbbae0-3b4d-43fc-b5d5-753792e2256b: node /foo
ff67a591-52cb-4d37-b826-772fe6611b7e: node /bar
ff67a591-52cb-4d37-b826-772fe6611b7e: node /bar
76dbbae0-3b4d-43fc-b5d5-753792e2256b: node /foo
{noformat}

Could you please fix that?



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

[jira] [Updated] (JCR-3924) Allow release-deploy to skip tests

[Davide Giannella (JIRA)]

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

Davide Giannella updated JCR-3924:
--
Attachment: JCR-3924.patch

A [patch|^JCR-3924.patch] that should allow us to provide a command
line like {{mvn release:perform -Ddeploy.arguments="-DskipTests"}} in
order to skip the tests during the deploy phase.

It's difficult to test it without applying it and performing a
release.

Can please someone review?


> Allow release-deploy to skip tests
> --
>
> Key: JCR-3924
> URL: https://issues.apache.org/jira/browse/JCR-3924
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Davide Giannella
>Assignee: Davide Giannella
>Priority: Blocker
> Fix For: 2.11.3
>
> Attachments: JCR-3924.patch
>
>
> As of now it seems impossible to skip tests during the release:perform part 
> of the release process.
> It is very annoying as often the upload fails and you have to re-execute from 
> scratch the full build which takes a lot of time.
> The inability to skip the tests with {{-DskipTest}} seems to be similar to 
> this [bug|https://issues.sonatype.org/browse/OSSRH-7663].
> By moving the deploy arguments to a custom variable it should be possible to 
> then provide an ad-hoc command line in case.



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

[jira] [Updated] (JCR-3924) Allow release-deploy to skip tests

[Davide Giannella (JIRA)]

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

Davide Giannella updated JCR-3924:
--
Fix Version/s: 2.11.3

> Allow release-deploy to skip tests
> --
>
> Key: JCR-3924
> URL: https://issues.apache.org/jira/browse/JCR-3924
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Fix For: 2.11.3
>
>
> As of now it seems impossible to skip tests during the release:perform part 
> of the release process.
> It is very annoying as often the upload fails and you have to re-execute from 
> scratch the full build which takes a lot of time.
> The inability to skip the tests with {{-DskipTest}} seems to be similar to 
> this [bug|https://issues.sonatype.org/browse/OSSRH-7663].
> By moving the deploy arguments to a custom variable it should be possible to 
> then provide an ad-hoc command line in case.



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

[jira] [Updated] (JCR-3924) Allow release-deploy to skip tests

[Davide Giannella (JIRA)]

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

Davide Giannella updated JCR-3924:
--
Priority: Blocker  (was: Major)

> Allow release-deploy to skip tests
> --
>
> Key: JCR-3924
> URL: https://issues.apache.org/jira/browse/JCR-3924
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Davide Giannella
>Assignee: Davide Giannella
>Priority: Blocker
> Fix For: 2.11.3
>
>
> As of now it seems impossible to skip tests during the release:perform part 
> of the release process.
> It is very annoying as often the upload fails and you have to re-execute from 
> scratch the full build which takes a lot of time.
> The inability to skip the tests with {{-DskipTest}} seems to be similar to 
> this [bug|https://issues.sonatype.org/browse/OSSRH-7663].
> By moving the deploy arguments to a custom variable it should be possible to 
> then provide an ad-hoc command line in case.



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

[jira] [Created] (JCR-3924) Allow release-deploy to skip tests

[Davide Giannella (JIRA)]

Davide Giannella created JCR-3924:
-

 Summary: Allow release-deploy to skip tests
 Key: JCR-3924
 URL: https://issues.apache.org/jira/browse/JCR-3924
 Project: Jackrabbit Content Repository
  Issue Type: Improvement
Reporter: Davide Giannella
Assignee: Davide Giannella


As of now it seems impossible to skip tests during the release:perform part of 
the release process.

It is very annoying as often the upload fails and you have to re-execute from 
scratch the full build which takes a lot of time.

The inability to skip the tests with {{-DskipTest}} seems to be similar to this 
[bug|https://issues.sonatype.org/browse/OSSRH-7663].

By moving the deploy arguments to a custom variable it should be possible to 
then provide an ad-hoc command line in case.



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

Jackrabbit-trunk - Build # 2328 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit-trunk (build #2328)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit-trunk/2328/ to 
view the results.

[jira] [Updated] (JCR-3913) Test failures: NodeLocalNameTest

[Davide Giannella (JIRA)]

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

Davide Giannella updated JCR-3913:
--
Fix Version/s: (was: 2.11.2)
   2.11.3

> Test failures: NodeLocalNameTest
> 
>
> Key: JCR-3913
> URL: https://issues.apache.org/jira/browse/JCR-3913
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>Reporter: Davide Giannella
> Fix For: 2.11.3
>
> Attachments: build-1443689505.log
>
>
> While building Jackrabbit on trunk I get the following failures:
> {noformat}
> NodeLocalNameTest>AbstractJCRTest.run:464->testPathLiteral:130 NodeName 
> comparison with absolute PATH must fail with InvalidQueryException
>   NodeLocalNameTest>AbstractJCRTest.run:464->testStringLiteralInvalidName:70 
> NodeName comparison with STRING that cannot be converted to NAME must fail 
> with InvalidQueryException
>   NodeLocalNameTest>AbstractJCRTest.run:464->testURILiteral:167 NodeName 
> comparison with URI that cannot be converted to NAME must fail with 
> InvalidQueryException
> {noformat}
> [full build logs|^build-1443689505.log]



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

[jira] [Updated] (JCR-3901) TCK LockManagerTest does not allow new JCR 2.0 for lock token transfers

[Davide Giannella (JIRA)]

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

Davide Giannella updated JCR-3901:
--
Fix Version/s: (was: 2.11.2)
   2.11.3

> TCK LockManagerTest does not allow new JCR 2.0 for lock token transfers
> ---
>
> Key: JCR-3901
> URL: https://issues.apache.org/jira/browse/JCR-3901
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: test
>Affects Versions: 2.10.1, 2.8.1, 2.11.0
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Fix For: 2.10.2, 2.8.2, 2.11.3
>
>
> testLockTransfer2() and testAddLockTokenToAnotherSession() assume that it's 
> always illegal to add lock tokens to multiple sessions, however 
>  allows 
> simultaneous lock ownership for open scoped locks.



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

[jira] [Updated] (JCR-3914) Support default aws region

[Davide Giannella (JIRA)]

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

Davide Giannella updated JCR-3914:
--
Fix Version/s: (was: 2.11.2)
   2.11.3

> Support default aws region
> --
>
> Key: JCR-3914
> URL: https://issues.apache.org/jira/browse/JCR-3914
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Affects Versions: 2.11.1
>Reporter: Carsten Ziegeler
>Assignee: Shashank Gupta
>Priority: Blocker
> Fix For: 2.11.3
>
> Attachments: JCR-3914.patch, patch.txt
>
>
> The aws s3 support (jackrabbit-aws-ext module) only supports providing the 
> credentials through a file and through an OSGi configuration. However, in 
> general all aws related services provide more configuration values, 
> especially when running aws it makes sense to support the metadata service.
> I suggest therefore to use 
> com.amazonaws.auth.DefaultAWSCredentialsProviderChain.
> Similar goes for the region, when running in aws, 
> Region region = Regions.getCurrentRegion();
> provides automatically the correct region.
> An OSGi configuration can be used for compatibility or testing to override 
> things



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