[jira] [Commented] (SLING-6782) Sling Job implementation should avoid unnecessary writes to the repository

[JIRA]

[ 
https://issues.apache.org/jira/browse/SLING-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975467#comment-15975467
 ] 

Jörg Hoh commented on SLING-6782:
-

For this case I adapted the ResourceHelper.getOrCreateResourceInternal a update 
and made the commit for the creation of the parentPath mandatory (updated 
patch).
But then we cannot remove this local copy of this method and replace it by the 
ResourceUtil version, because there the commit of creation of the parentPath 
should still depend on autoCommit.

> Sling Job implementation should avoid unnecessary writes to the repository
> --
>
> Key: SLING-6782
> URL: https://issues.apache.org/jira/browse/SLING-6782
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.2.2
>Reporter: Jörg Hoh
> Attachments: SLING-6782-jobs-commit-to-often-2.patch, 
> SLING-6782-jobs-commit-to-often.patch
>
>
> I found in a number of occurences in the Sling Event code this pattern:
> {code}
> ResourceHelper.getOrCreateResource(resolver, newPath, 
> props);
> resolver.delete(jobResource);
> resolver.commit();
> {code}
> and the getOrCreateResource is internally doing a commit on the resolver 
> (autoCommit = true). So in the end there are 2 commits while only a single 
> commit would be sufficient.
> Removing these "double" commits could avoid a few write operations on the 
> repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6782) Sling Job implementation should avoid unnecessary writes to the repository

[JIRA]

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

Jörg Hoh updated SLING-6782:

Attachment: SLING-6782-jobs-commit-to-often-2.patch

> Sling Job implementation should avoid unnecessary writes to the repository
> --
>
> Key: SLING-6782
> URL: https://issues.apache.org/jira/browse/SLING-6782
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.2.2
>Reporter: Jörg Hoh
> Attachments: SLING-6782-jobs-commit-to-often-2.patch, 
> SLING-6782-jobs-commit-to-often.patch
>
>
> I found in a number of occurences in the Sling Event code this pattern:
> {code}
> ResourceHelper.getOrCreateResource(resolver, newPath, 
> props);
> resolver.delete(jobResource);
> resolver.commit();
> {code}
> and the getOrCreateResource is internally doing a commit on the resolver 
> (autoCommit = true). So in the end there are 2 commits while only a single 
> commit would be sufficient.
> Removing these "double" commits could avoid a few write operations on the 
> repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6782) Sling Job implementation should avoid unnecessary writes to the repository

[JIRA]

[ 
https://issues.apache.org/jira/browse/SLING-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975316#comment-15975316
 ] 

Jörg Hoh commented on SLING-6782:
-

Hi Carsten,

good point. But from my point of view in the context of Sling Jobs, 
autoCommit=false would never make sense for the creation of the parent path. So 
we should ignore this flag for that in any case and always do the commit. And 
only act on autoCommit when it's about saving the resoource.

> Sling Job implementation should avoid unnecessary writes to the repository
> --
>
> Key: SLING-6782
> URL: https://issues.apache.org/jira/browse/SLING-6782
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.2.2
>Reporter: Jörg Hoh
> Attachments: SLING-6782-jobs-commit-to-often.patch
>
>
> I found in a number of occurences in the Sling Event code this pattern:
> {code}
> ResourceHelper.getOrCreateResource(resolver, newPath, 
> props);
> resolver.delete(jobResource);
> resolver.commit();
> {code}
> and the getOrCreateResource is internally doing a commit on the resolver 
> (autoCommit = true). So in the end there are 2 commits while only a single 
> commit would be sufficient.
> Removing these "double" commits could avoid a few write operations on the 
> repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6782) Sling Job implementation should avoid unnecessary writes to the repository

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15975448#comment-15975448
 ] 

Carsten Ziegeler commented on SLING-6782:
-

Right - I thought that's exactly what I wrote :)

> Sling Job implementation should avoid unnecessary writes to the repository
> --
>
> Key: SLING-6782
> URL: https://issues.apache.org/jira/browse/SLING-6782
> Project: Sling
>  Issue Type: Improvement
>  Components: Event
>Affects Versions: Event 4.2.2
>Reporter: Jörg Hoh
> Attachments: SLING-6782-jobs-commit-to-often.patch
>
>
> I found in a number of occurences in the Sling Event code this pattern:
> {code}
> ResourceHelper.getOrCreateResource(resolver, newPath, 
> props);
> resolver.delete(jobResource);
> resolver.commit();
> {code}
> and the getOrCreateResource is internally doing a commit on the resolver 
> (autoCommit = true). So in the end there are 2 commits while only a single 
> commit would be sufficient.
> Removing these "double" commits could avoid a few write operations on the 
> repository.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Maven Content Package Plugin

[Andreas Schaefer Sr.]

Hi

I started working on making the wcm-io content package maven plugin to work
with Composum so that JCR content packages can be deployed w/o Adobe’s
maven plugin.

For that I created a ticket here:

https://wcm-io.atlassian.net/browse/WTOOL-29

Cheers - Andy

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.resource (was: event.impl)

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15974457#comment-15974457
 ] 

Stefan Egli commented on SLING-6739:


bq. However we should not change the bundle symbolic name, otherwise this 
bundle could not be used for updating an older version.
good point. in that case I guess the most straight-forward way would be to 
leave the artifactId unchanged indeed - otherwise we have to explicitly set the 
bundle symbolic name and it might be difficult to argue why a different 
artifactId vs symbolic name (or at least not as straight-forward as leaving it 
the same). So let's to go for {{org.apache.sling.event}} 4.3.0

> split sling.event into event.api and event.resource (was: event.impl)
> -
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event/api
> bundles/extensions/event/resource
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.resource (was: event.impl)

[Stefan Egli (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15974409#comment-15974409
 ] 

Stefan Egli commented on SLING-6739:


h6. step 11 : sling.event.api 1.0.0 vote succeeded, release done

next step: embedding event.api into event.resource and releasing it. In theory 
nothing changes for users of the event.resource bundle, but we're likely going 
to change the artifactId. So the question is, what version should 
event.resource be getting, is it 1.0.0 or 4.3.0 or 4.2.4. 

[~cziegeler], wdyt?

> split sling.event into event.api and event.resource (was: event.impl)
> -
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event/api
> bundles/extensions/event/resource
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.resource (was: event.impl)

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SLING-6739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15974445#comment-15974445
 ] 

Carsten Ziegeler commented on SLING-6739:
-

Not sure if we need to change the artifact id - it might make sense. However we 
should not change the bundle symbolic name, otherwise this bundle could not be 
used for updating an older version. Therefore we continue with version in the 
4.x range. 4.3.0 sounds good to me

> split sling.event into event.api and event.resource (was: event.impl)
> -
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Event API 1.0.0
>
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event/api
> bundles/extensions/event/resource
> and to remove the current
> bundles/extensions/event



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [VOTE] Release Apache Sling Event API 1.0.0 (initial release)

[Stefan Egli]

+1

Cheers,
Stefan

On 12/04/17 10:32, "Stefan Egli"  wrote:

>Hi,
>
>This is about the first (API) part of splitting Sling Event into two
>bundles (API and Impl). Since it is an initial release it might make sense
>to review the pom extra this time. This split is tracked in:
>
>https://issues.apache.org/jira/browse/SLING-6739
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1686
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1686 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>Stefan
>
>

[RESULT][VOTE] Release Apache Sling Event API 1.0.0 (initial release)

[Stefan Egli]

The vote succeeded with 3 binding and one non-binding votes. I'll proceed
with the release next.

Cheers,
Stefan

On 12/04/17 10:32, "Stefan Egli"  wrote:

>Hi,
>
>This is about the first (API) part of splitting Sling Event into two
>bundles (API and Impl). Since it is an initial release it might make sense
>to review the pom extra this time. This split is tracked in:
>
>https://issues.apache.org/jira/browse/SLING-6739
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1686
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1686 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>Stefan
>
>