[jira] [Resolved] (SLING-8468) [slingfeature-m-p] donate a new MOJO which is able to scan and detect differences between different versions of the same Feature model
[
https://issues.apache.org/jira/browse/SLING-8468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SLING-8468.
---
Resolution: Fixed
PR https://github.com/apache/sling-slingfeature-maven-plugin/pull/32 merged
> [slingfeature-m-p] donate a new MOJO which is able to scan and detect
> differences between different versions of the same Feature model
> --
>
> Key: SLING-8468
> URL: https://issues.apache.org/jira/browse/SLING-8468
> Project: Sling
> Issue Type: New Feature
> Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: slingfeature-maven-plugin 1.0.2
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I would like to donate a new {{features-diff}} MOJO I developed in the spare
> time that could be helpful detecting systems evolution.
> I got inspiration from my previous contribution of the [Felix
> Baseline|https://felix.apache.org/components/bundle-plugin/baseline-mojo.html]
> MOJO, users can configure the feature selection (inherited by the
> {{AbstractIncludingFeatureMojo}}) and the previously released version of the
> they are interested comparing, i.e.:
> {noformat}
>
> org.apache.sling
> slingfeature-maven-plugin
>
>
> features-diff
> package
>
> features-diff
>
>
> 1.0.2
>
> cloud-ready
> base
>
> {noformat}
> then the plugin will take care of resolving the configured version of
> selected classified Feature and compare each other, producing the outputs in
> the {{target/features-diff/.diff.json}} files, enlisting for each
> Feature section what was added/removed/changed.
> The new MOJO relies on the [Feature Model API Regions
> model|https://github.com/apache/sling-org-apache-sling-feature-apiregions-model]
> and the [Feature
> Diff|https://github.com/apache/sling-whiteboard/tree/master/feature-diff]
> (still in the whiteboard) which contains the core implementation of the diff
> tool.
> I will start pushing the MOJO in a separated branch in order to discuss the
> development evolution.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [sling-slingfeature-maven-plugin] simonetripodi merged pull request #32: SLING-8468 - [slingfeature-m-p] donate a new MOJO which is able to scan and detect differences between different versi
simonetripodi merged pull request #32: SLING-8468 - [slingfeature-m-p] donate a new MOJO which is able to scan and detect differences between different versions of the same Feature model URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/32 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
+1 I like your idea! I vaguely remember having similar thoughts in the past, but considered it too much effort for what I was after at the time. Regards Julian On Fri, Jul 5, 2019 at 3:41 PM Jason E Bailey wrote: > > +1 for this idea > > -- > Jason > > On Thu, Jul 4, 2019, at 11:55 AM, Radu Cotescu wrote: > > Let me add more details. Three classes use JCR or JackRabbit dependencies: > > > > JcrXmlContentParser > > JcrXmlValueConverter > > XmlContentParser > > ParserHelper > > > > What I’d suggest would be to separate the API from the implementation > > and then provide the parsers from different pluggable modules. In > > addition to that, I think that the ParserHelper could maybe be exposed > > in the API as a final class, much like the ContentParserFactory, and > > use a different Calendar parser instead of > > org.apache.jackrabbit.util.ISO8601. > > > > I could prepare a PR if you agree with the changes. > > > > Thanks, > > Radu > > > > > On 4 Jul 2019, at 17:00, Radu Cotescu wrote: > > > > > > Hi Stefan, > > > > > > I do know that the module has JCR in its name, but do you think that we > > > could make the JCR stuff optional? I’d really like to reuse this module > > > to parse JSON into Sling resource trees, but I’d like the JCR > > > dependencies to be optional, since in my experimental setup I use a > > > different resource provider. > > > > > > Thanks, > > > Radu > > > >
[GitHub] [sling-slingfeature-maven-plugin] simonetripodi commented on issue #32: SLING-8468 - [slingfeature-m-p] donate a new MOJO which is able to scan and detect differences between different versio
simonetripodi commented on issue #32: SLING-8468 - [slingfeature-m-p] donate a new MOJO which is able to scan and detect differences between different versions of the same Feature model URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/32#issuecomment-508808382 @bosschaert @cziegeler automatic checks have failed but now that the `org.apache.sling:org.apache.sling.feature.diff:0.0.2` is available on the public repo, build succeed and PR can be merged This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [DISCUSS] Support ZonedDateTime in ValueMap
The parent POM was updated to Java a while back, my understanding is if you need to update a bundle to 8 as part of a story, there's no need for a separate story. -- Jason On Fri, Jul 5, 2019, at 10:39 AM, Julian Sedding wrote: > Hi all > > I've implemented these changes, but I had to increase the required > java version of JCR Resource to Java 8 (given ZonedDateTime was > introduced in Java 8). > > Is that ok? Should I create a separate ticket for the Java version > increase? And should I increase the bundle version as well, since its > compatibility changes? > > Regards > Julian > > > On Thu, Jul 4, 2019 at 6:18 PM Julian Sedding wrote: > > > > That should have read: > > > > 've created SLING-8558 for tracking the change in ValueMapDecorator > > (API) and SLING-8559 for tracking the change in JcrValueMap (JCR > > Resource) for now. > > > > Regards > > Julian > > > > On Thu, Jul 4, 2019 at 12:09 PM Julian Sedding wrote: > > > > > > Thanks Robert. > > > > > > I've created SLING-8558 for tracking the change in ValueMapDecorator > > > (API) and JcrValueMap (JCR Resource) for now. > > > > > > Regards > > > Julian > > > > > > On Tue, Jul 2, 2019 at 12:05 PM Robert Munteanu > > > wrote: > > > > > > > > On Tue, 2019-07-02 at 12:01 +0200, Julian Sedding wrote: > > > > > Hi all > > > > > > > > > > I think it might make sense to support getting dates from ValueMaps > > > > > as > > > > > java.time.ZonedDateTime instances directly. I've been finding myself > > > > > converting Calendar instances after retrieving them from ValueMaps > > > > > quite a bit lately. > > > > > > > > Sounds good to me. Some notes: > > > > > > > > - calendar instances also have time zones attached, so we don't > > > > introduce anything suprising by returning dates with time zones > > > > attached. > > > > - we don't bump up the required JVM version as ZonedDateTime is > > > > available with Java >= 8. > > > > > > > > Robert > > > > >
Re: [DISCUSS] Support ZonedDateTime in ValueMap
Hi all I've implemented these changes, but I had to increase the required java version of JCR Resource to Java 8 (given ZonedDateTime was introduced in Java 8). Is that ok? Should I create a separate ticket for the Java version increase? And should I increase the bundle version as well, since its compatibility changes? Regards Julian On Thu, Jul 4, 2019 at 6:18 PM Julian Sedding wrote: > > That should have read: > > 've created SLING-8558 for tracking the change in ValueMapDecorator > (API) and SLING-8559 for tracking the change in JcrValueMap (JCR > Resource) for now. > > Regards > Julian > > On Thu, Jul 4, 2019 at 12:09 PM Julian Sedding wrote: > > > > Thanks Robert. > > > > I've created SLING-8558 for tracking the change in ValueMapDecorator > > (API) and JcrValueMap (JCR Resource) for now. > > > > Regards > > Julian > > > > On Tue, Jul 2, 2019 at 12:05 PM Robert Munteanu wrote: > > > > > > On Tue, 2019-07-02 at 12:01 +0200, Julian Sedding wrote: > > > > Hi all > > > > > > > > I think it might make sense to support getting dates from ValueMaps > > > > as > > > > java.time.ZonedDateTime instances directly. I've been finding myself > > > > converting Calendar instances after retrieving them from ValueMaps > > > > quite a bit lately. > > > > > > Sounds good to me. Some notes: > > > > > > - calendar instances also have time zones attached, so we don't > > > introduce anything suprising by returning dates with time zones > > > attached. > > > - we don't bump up the required JVM version as ZonedDateTime is > > > available with Java >= 8. > > > > > > Robert > > >
[jira] [Commented] (SLING-8564) commons html - Make HTML5 parser default
[ https://issues.apache.org/jira/browse/SLING-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879332#comment-16879332 ] Jason E Bailey commented on SLING-8564: --- Plan is to make the HTML4 parser require an OSGi Configuration. Currently testing solution in a production environment. > commons html - Make HTML5 parser default > > > Key: SLING-8564 > URL: https://issues.apache.org/jira/browse/SLING-8564 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Priority: Minor > Fix For: Commons HTML 1.1.2 > > > Currently two parsers are available, an HTML4 parser and an HTML5 parser. To > use of the HTML5 parser the HTML4 needs to be disabled. HTML5 should be the > priority unless the HTML4 is specifically needed. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8559) JcrValueMap should allow getting ZonedDateTime values
[
https://issues.apache.org/jira/browse/SLING-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879331#comment-16879331
]
Julian Sedding commented on SLING-8559:
---
Increased required java version to 8 and fixed missing license header with
[commit
857e305|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-resource.git;a=commitdiff;h=857e305].
> JcrValueMap should allow getting ZonedDateTime values
> -
>
> Key: SLING-8559
> URL: https://issues.apache.org/jira/browse/SLING-8559
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Affects Versions: JCR Resource 3.0.18
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: JCR Resource 3.0.20
>
>
> It would be convenient to allow getting {{ZonedDateTime}} values from a
> {{ValueMap}}, which is a straight forward conversion from Calendar.
> The {{JcrValueMap}} should be extended accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SLING-8564) commons html - Make HTML5 parser default
[ https://issues.apache.org/jira/browse/SLING-8564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason E Bailey updated SLING-8564: -- Fix Version/s: Commons HTML 1.1.2 > commons html - Make HTML5 parser default > > > Key: SLING-8564 > URL: https://issues.apache.org/jira/browse/SLING-8564 > Project: Sling > Issue Type: Improvement >Reporter: Jason E Bailey >Priority: Minor > Fix For: Commons HTML 1.1.2 > > > Currently two parsers are available, an HTML4 parser and an HTML5 parser. To > use of the HTML5 parser the HTML4 needs to be disabled. HTML5 should be the > priority unless the HTML4 is specifically needed. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SLING-8564) commons html - Make HTML5 parser default
Jason E Bailey created SLING-8564: - Summary: commons html - Make HTML5 parser default Key: SLING-8564 URL: https://issues.apache.org/jira/browse/SLING-8564 Project: Sling Issue Type: Improvement Reporter: Jason E Bailey Currently two parsers are available, an HTML4 parser and an HTML5 parser. To use of the HTML5 parser the HTML4 needs to be disabled. HTML5 should be the priority unless the HTML4 is specifically needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SLING-8558) ValueMapDecorator should allow getting ZonedDateTime values
[
https://issues.apache.org/jira/browse/SLING-8558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879327#comment-16879327
]
Julian Sedding commented on SLING-8558:
---
Fixed test case with [commit
6d294ee|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-api.git;a=commitdiff;h=6d294ee].
> ValueMapDecorator should allow getting ZonedDateTime values
> ---
>
> Key: SLING-8558
> URL: https://issues.apache.org/jira/browse/SLING-8558
> Project: Sling
> Issue Type: Improvement
> Components: API
>Affects Versions: API 2.20.0
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: API 2.20.2
>
>
> It would be convenient to allow getting {{ZonedDateTime}} values from a
> {{ValueMap}}, which is a straight forward conversion from Calendar.
> The {{ObjectConverter}} used in {{ValueMapDecorator}} should be extended
> accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [org.apache.sling.jcr.contentparser] can we decouple it from JCR?
+1 for this idea -- Jason On Thu, Jul 4, 2019, at 11:55 AM, Radu Cotescu wrote: > Let me add more details. Three classes use JCR or JackRabbit dependencies: > > JcrXmlContentParser > JcrXmlValueConverter > XmlContentParser > ParserHelper > > What I’d suggest would be to separate the API from the implementation > and then provide the parsers from different pluggable modules. In > addition to that, I think that the ParserHelper could maybe be exposed > in the API as a final class, much like the ContentParserFactory, and > use a different Calendar parser instead of > org.apache.jackrabbit.util.ISO8601. > > I could prepare a PR if you agree with the changes. > > Thanks, > Radu > > > On 4 Jul 2019, at 17:00, Radu Cotescu wrote: > > > > Hi Stefan, > > > > I do know that the module has JCR in its name, but do you think that we > > could make the JCR stuff optional? I’d really like to reuse this module to > > parse JSON into Sling resource trees, but I’d like the JCR dependencies to > > be optional, since in my experimental setup I use a different resource > > provider. > > > > Thanks, > > Radu > >
[jira] [Updated] (SLING-8545) Mails are missing proper date header
[ https://issues.apache.org/jira/browse/SLING-8545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-8545: --- Component/s: Tooling > Mails are missing proper date header > > > Key: SLING-8545 > URL: https://issues.apache.org/jira/browse/SLING-8545 > Project: Sling > Issue Type: Bug > Components: Tooling >Reporter: Oliver Lietz >Assignee: Radu Cotescu >Priority: Major > Fix For: Committer CLI 1.0.0 > > Attachments: mail-list-vote.png > > Time Spent: 20m > Remaining Estimate: 0h > > There are some release vote mails from [~rombert] and [~radu.cotescu] where > the date header is missing and they got "lost" in my mail client. I *guess* > the mails were sent via Committer CLI. > !mail-list-vote.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (SLING-8559) JcrValueMap should allow getting ZonedDateTime values
[
https://issues.apache.org/jira/browse/SLING-8559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding resolved SLING-8559.
---
Resolution: Fixed
Fix Version/s: JCR Resource 3.0.20
Fixed with [commit
6289711|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-resource.git;a=commitdiff;h=6289711].
> JcrValueMap should allow getting ZonedDateTime values
> -
>
> Key: SLING-8559
> URL: https://issues.apache.org/jira/browse/SLING-8559
> Project: Sling
> Issue Type: Improvement
> Components: JCR
>Affects Versions: JCR Resource 3.0.18
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: JCR Resource 3.0.20
>
>
> It would be convenient to allow getting {{ZonedDateTime}} values from a
> {{ValueMap}}, which is a straight forward conversion from Calendar.
> The {{JcrValueMap}} should be extended accordingly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (SLING-8535) RepoInit register privilege fails if privilege already exists
[ https://issues.apache.org/jira/browse/SLING-8535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-8535. - > RepoInit register privilege fails if privilege already exists > - > > Key: SLING-8535 > URL: https://issues.apache.org/jira/browse/SLING-8535 > Project: Sling > Issue Type: Bug > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.10 >Reporter: Karl Pauls >Assignee: Karl Pauls >Priority: Major > Fix For: Repoinit JCR 1.1.12 > > > The PrivilegeVisitor does assume that a registerPriv does work if the priv is > already defined. That is wrong as at least currently, it throws an > implementation specific exception. We need to check if the priv exists first > as a consequence as repoinit needs to be idempotent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (SLING-8532) Repoinit parser fails with privilege including a : character
[
https://issues.apache.org/jira/browse/SLING-8532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls closed SLING-8532.
-
> Repoinit parser fails with privilege including a : character
>
>
> Key: SLING-8532
> URL: https://issues.apache.org/jira/browse/SLING-8532
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
>Affects Versions: Repoinit Parser 1.2.4
>Reporter: Christophe Jelger
>Assignee: Karl Pauls
>Priority: Major
> Fix For: Repoinit Parser 1.2.6
>
> Attachments: changes.patch
>
>
> The repoinit parser fails when it encounters a privilege with a : character
> like:
> {code:java}
> register privilege crx:replicate{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re:[RESULT] [VOTE] Release Apache Sling JCR Repoinit 1.1.12
Time to call the vote on the Apache Sling JCR Repoinit 1.1.12 release. * +1 votes from Carsten Ziegeler, Simone Tripodi, Robert Munteanu, Andreas Schaefer, Stefan Seifert, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [RESULT][VOTE] Release Apache Sling Repoinit Parser 1.2.6
Time to call the vote on the Apache Sling Repoinit Parser 1.2.6 release. * +1 votes from Stefan Seifert, Carsten Ziegeler, Andreas Schaefer, Timothee Maret, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling JCR Repoinit 1.1.12
+1 regards, Karl On Wed, Jun 26, 2019 at 9:17 PM Stefan Seifert wrote: > > +1 > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Sling Repoinit Parser 1.2.6
+1 regards, Karl On Fri, Jul 5, 2019 at 2:03 PM Karl Pauls wrote: > > +1 > > regards, > > Karl > > On Tue, Jun 25, 2019 at 8:00 PM Timothee Maret wrote: > > > > +1, > > > > Regards, > > > > Timothee > > > > Le mar. 25 juin 2019 à 17:12, Andreas Schaefer a > > écrit : > > > > > +1 (non-binding) > > > > > > - Andy > > > > > > > On Jun 25, 2019, at 3:53 AM, Karl Pauls wrote: > > > > > > > > I would like to call a vote on the Apache Sling Repoinit Parser 1.2.6 > > > release. > > > > > > > > We solved 1 issue in this release: > > > > > > > > https://issues.apache.org/jira/projects/SLING/versions/12345439 > > > > > > > > Staging repository: > > > > https://repository.apache.org/content/repositories/orgapachesling-2100/ > > > > > > > > You can use this UNIX script to download the release and verify the > > > signatures: > > > > > > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > > > > > > > Usage: > > > > sh check_staged_release.sh 2100 /tmp/sling-staging > > > > > > > > Please vote to approve these release: > > > > > > > > [ ] +1 Approve the releases > > > > [ ] 0 Don't care > > > > [ ] -1 Don't release, because ... > > > > > > > > > > -- > Karl Pauls > karlpa...@gmail.com -- Karl Pauls karlpa...@gmail.com
[jira] [Closed] (SLING-8495) Make FSClassLoader its cache location root directory configurable
[ https://issues.apache.org/jira/browse/SLING-8495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls closed SLING-8495. - > Make FSClassLoader its cache location root directory configurable > - > > Key: SLING-8495 > URL: https://issues.apache.org/jira/browse/SLING-8495 > Project: Sling > Issue Type: Improvement > Components: Commons >Affects Versions: File System ClassLoader 1.0.10 >Reporter: Krystian Nowak >Assignee: Karl Pauls >Priority: Major > Fix For: File System ClassLoader 1.0.12 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently FSClassLoader's cache location is on the bundle persistent storage > area. > In cases when it would make more sense to externalize it to a different > location, file system cache location root directory needs to be configurable. > For that > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderProvider.java#L108] > needs to be made parametrized to have its "root" directory configurable. > Also: > * > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderWebConsole.java#L95] > * > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderMBeanImpl.java#L79] > * > [https://github.com/apache/sling-org-apache-sling-commons-fsclassloader/blob/master/src/main/java/org/apache/sling/commons/fsclassloader/impl/FSClassLoaderMBeanImpl.java#L109] > should be changed accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Sling Repoinit Parser 1.2.6
+1 regards, Karl On Tue, Jun 25, 2019 at 8:00 PM Timothee Maret wrote: > > +1, > > Regards, > > Timothee > > Le mar. 25 juin 2019 à 17:12, Andreas Schaefer a > écrit : > > > +1 (non-binding) > > > > - Andy > > > > > On Jun 25, 2019, at 3:53 AM, Karl Pauls wrote: > > > > > > I would like to call a vote on the Apache Sling Repoinit Parser 1.2.6 > > release. > > > > > > We solved 1 issue in this release: > > > > > > https://issues.apache.org/jira/projects/SLING/versions/12345439 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachesling-2100/ > > > > > > You can use this UNIX script to download the release and verify the > > signatures: > > > > > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD > > > > > > Usage: > > > sh check_staged_release.sh 2100 /tmp/sling-staging > > > > > > Please vote to approve these release: > > > > > > [ ] +1 Approve the releases > > > [ ] 0 Don't care > > > [ ] -1 Don't release, because ... > > > > -- Karl Pauls karlpa...@gmail.com
Re: [RESULT][VOTE] Release Apache Sling File System Classloader 1.0.12
Time to call the vote on the Apache SlingFile System Classloader 1.0.12 release. * +1 votes from Carsten Ziegeler, Robert Munteanu, Stefan Seifert, Andreas Schaefer, and Karl Pauls. * No other votes. The vote is successful. I will make the artifacts available as soon as possible.
Re: [VOTE] Release Apache Sling File System Classloader 1.0.12
+1 regards, Karl On Mon, Jun 17, 2019 at 3:02 PM Karl Pauls wrote: > > I would like to call a vote on the following release, > > Apache Sling File System Classloader 1.0.12 > > We solved 1 issue in this release: > https://issues.apache.org/jira/projects/SLING/versions/12345673 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2096/ > > 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 2096 /tmp/sling-staging > > Please vote to approve these releases: > > [ ] +1 Approve the releases > [ ] 0 Don't care > [ ] -1 Don't release, because ... -- Karl Pauls karlpa...@gmail.com
Re: Build error on Java 11 - Upgrade of maven-surefire-plugin version on sling parent?
Sorry for the noise .. there is a version 35 of the pom which works. I tried to set this version in eclipse before and wrongly interpreted an error as the artifact not being available. Christian Am Fr., 5. Juli 2019 um 11:32 Uhr schrieb Christian Schneider < ch...@die-schneider.net>: > The latest released parent is 34 which does not yet work.. > > Unfortunately I missed to check master .. There we already use 3.0.0-M3 > which should be fine.. > So my question is wrong :-) > The correct question is: Should we release the parent with those changes? > Is a milestone release of surefire ready for prime time? > > An alternative would be to switch back to 2.22.2 and release this. We > could then switch to surefire 3 once it is released. > > WDYT? > > Christian > > Am Fr., 5. Juli 2019 um 10:55 Uhr schrieb Radu Cotescu : > >> Hi Christian, >> >> > On 5 Jul 2019, at 10:02, Christian Schneider >> wrote: >> > >> > I have found an issue when build a sling bundle on Java 11. >> > https://issues.apache.org/jira/browse/SLING-8563 >> > >> > It seems that the error is caused by the maven-surefire-plugin we use ( >> > 2.20.1) in parent not being compatible to Java 11. >> > I was able to fix the build by using a newer version (2.22.2) in this >> > bundle. >> > >> >> Have you tried updating the parent you’re using [0]? >> >> Cheers, >> Radu >> >> [0] - >> https://github.com/apache/sling-parent/blob/sling-parent-reactor-35/sling-parent/pom.xml#L61 >> >> > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
[jira] [Commented] (SLING-8563) Error when building messages bundle with java 11
[ https://issues.apache.org/jira/browse/SLING-8563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879168#comment-16879168 ] Christian Schneider commented on SLING-8563: You are totally right .. there is a version 35 and it works. I tried to change the version to 35 before and got an error in eclipse on the pom which I wrongly interpreted as the pom being not found .. but it was a different error. So sorry about the noise .. I upgraded the parent and it works fine. > Error when building messages bundle with java 11 > > > Key: SLING-8563 > URL: https://issues.apache.org/jira/browse/SLING-8563 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Messages 0.1.0 >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Messages 0.1.2 > > > [*ERROR*] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test *(default-test)* > on project org.apache.sling.distribution.journal.messages: *Execution > default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.*: > NullPointerException -> [Help 1] > From the linked discussion it seems the maven-surefire-plugin 2.20.1 is not > compatible to Java 11. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[RESULT][VOTE] Release Sling Feature additional Components
Hi all, more than 72h have passed and the current vote can be closed and passes with following resolution: Three +1 binding votes from PMCs: * David Bosschaert * Robert Munteanu * Andrei Dulvac Two additional non-binding +1 votes from: * Simone Tripodi * Andreas Schaefer No other votes were cast. I am going ahead on promoting release bundles. Thanks everyone who took part to the review process. All the best, ~Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Jul 2, 2019 at 4:25 PM Simone Tripodi wrote: > > Hi all, > > I would like to call the massive release on the following components: > > org.apache.sling.feature.diff-0.0.2 > this is the very first release > > org.apache.sling.feature.r2f-0.0.2 > this is the very first release > > org.apache.sling.feature.apiregions.model-0.0.2 > this is the very first release > > org.apache.sling.feature.inventoryprinter-1.0.2 > fixed issues: > SLING-8542 Generate feature model from running AEM instance > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2103/ > > 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 2092 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours and closes on > ~2019-07-05 at 4:30pm GMT+2 > > Best regards, > ~Simo > > http://people.apache.org/~simonetripodi/ > http://twitter.com/simonetripodi
[jira] [Commented] (SLING-8563) Error when building messages bundle with java 11
[ https://issues.apache.org/jira/browse/SLING-8563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879156#comment-16879156 ] Oliver Lietz commented on SLING-8563: - [~cschneider], Sling Bundle Parent 35 works fine. Search for "compliant with Java 9 and higher" in JIRA. > Error when building messages bundle with java 11 > > > Key: SLING-8563 > URL: https://issues.apache.org/jira/browse/SLING-8563 > Project: Sling > Issue Type: Bug > Components: Content Distribution >Affects Versions: Content Distribution Journal Messages 0.1.0 >Reporter: Christian Schneider >Assignee: Christian Schneider >Priority: Major > Fix For: Content Distribution Journal Messages 0.1.2 > > > [*ERROR*] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test *(default-test)* > on project org.apache.sling.distribution.journal.messages: *Execution > default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.*: > NullPointerException -> [Help 1] > From the linked discussion it seems the maven-surefire-plugin 2.20.1 is not > compatible to Java 11. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Build error on Java 11 - Upgrade of maven-surefire-plugin version on sling parent?
The latest released parent is 34 which does not yet work.. Unfortunately I missed to check master .. There we already use 3.0.0-M3 which should be fine.. So my question is wrong :-) The correct question is: Should we release the parent with those changes? Is a milestone release of surefire ready for prime time? An alternative would be to switch back to 2.22.2 and release this. We could then switch to surefire 3 once it is released. WDYT? Christian Am Fr., 5. Juli 2019 um 10:55 Uhr schrieb Radu Cotescu : > Hi Christian, > > > On 5 Jul 2019, at 10:02, Christian Schneider > wrote: > > > > I have found an issue when build a sling bundle on Java 11. > > https://issues.apache.org/jira/browse/SLING-8563 > > > > It seems that the error is caused by the maven-surefire-plugin we use ( > > 2.20.1) in parent not being compatible to Java 11. > > I was able to fix the build by using a newer version (2.22.2) in this > > bundle. > > > > Have you tried updating the parent you’re using [0]? > > Cheers, > Radu > > [0] - > https://github.com/apache/sling-parent/blob/sling-parent-reactor-35/sling-parent/pom.xml#L61 > > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
Re: Build error on Java 11 - Upgrade of maven-surefire-plugin version on sling parent?
Hi Christian, > On 5 Jul 2019, at 10:02, Christian Schneider wrote: > > I have found an issue when build a sling bundle on Java 11. > https://issues.apache.org/jira/browse/SLING-8563 > > It seems that the error is caused by the maven-surefire-plugin we use ( > 2.20.1) in parent not being compatible to Java 11. > I was able to fix the build by using a newer version (2.22.2) in this > bundle. > Have you tried updating the parent you’re using [0]? Cheers, Radu [0] - https://github.com/apache/sling-parent/blob/sling-parent-reactor-35/sling-parent/pom.xml#L61
Build error on Java 11 - Upgrade of maven-surefire-plugin version on sling parent?
I have found an issue when build a sling bundle on Java 11. https://issues.apache.org/jira/browse/SLING-8563 It seems that the error is caused by the maven-surefire-plugin we use ( 2.20.1) in parent not being compatible to Java 11. I was able to fix the build by using a newer version (2.22.2) in this bundle. So my question is: Should I update the sling parent to this new version or are there known issues with it? Christian -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
[jira] [Created] (SLING-8563) Error when building messages bundle with java 11
Christian Schneider created SLING-8563: -- Summary: Error when building messages bundle with java 11 Key: SLING-8563 URL: https://issues.apache.org/jira/browse/SLING-8563 Project: Sling Issue Type: Bug Components: Content Distribution Affects Versions: Content Distribution Journal Messages 0.1.0 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: Content Distribution Journal Messages 0.1.2 [*ERROR*] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test *(default-test)* on project org.apache.sling.distribution.journal.messages: *Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.*: NullPointerException -> [Help 1] >From the linked discussion it seems the maven-surefire-plugin 2.20.1 is not >compatible to Java 11. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
