[jira] [Commented] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)
[ https://issues.apache.org/jira/browse/SLING-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168639#comment-16168639 ] Timothee Maret commented on SLING-7061: --- [~bdelacretaz] I implemented the initial syntax you proposed, in https://github.com/tmaret/sling/commit/2221f54d58b8bdcaa8e7bee4dcd06473a076eb1b > Access control setup of repository-level permissions (i.e. null path) > - > > Key: SLING-7061 > URL: https://issues.apache.org/jira/browse/SLING-7061 > Project: Sling > Issue Type: Improvement > Components: Repoinit >Affects Versions: Repoinit Parser 1.1.0 >Reporter: angela >Assignee: Timothee Maret > Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6 > > > If I am not mistaken it is currently not possible to create access control > setup for principals at the 'null' path, which according to JSR 283 is to be > used to setup repository level permissions such as > - node type definition management (i.e. registering new node types) > - namespace management (i.e. registering new namespaces) > - privilege management (i.e. registering new privileges) > - workspace management (i.e. creating/removing workspaces) > All of these operations are not bound to a path (like e.g. removing an item > or creating a new version for a given node) but instead take global effect on > the whole JCR repository... that's why permissions for these operations > cannot be granted at a given path. > In the default authorization model shipped with Jackrabbit and Oak the -null- > path access control policy is stored with a dedicated _rep:repoPolicy_ node > located with the root node and > For service user definitions we need to be able to define entries for the > -null- path policy for the reasons explained above. Thanks for extending the > repo-init accordingly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: Java 9, parent pom and maven-antrun-plugin removal
Konrad Windszus wrote > Some more investigations on that: > > The BREE header is deprecated since OSGi 4.3 > (https://www.infoq.com/news/2011/03/osgi-43). I don't think we should > generate it any longer. Instead we should only rely on the Require-Capability > which is being generated by bnd automatically based on the class version > (compare with http://bnd.bndtools.org/instructions/noee.html and > https://github.com/bndtools/bnd/blob/41056e2507e9781d17aeaf66a00b35370a63043d/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L772) Good point, in fact the OSGi spec states that a bundle should not use both at the same time - which we actually do. So removing the BREE header simplifies everything Regards Carsten > > Regarding the animal-sniffer-plugin: > 1) There is not yet a Java 9 signature (i.e. requiring java9 for Sling > Modules does not work yet) > 2) Javac 9 comes with bootclasspaths for Java 6, Java 7 and Java 8 (see > https://stackoverflow.com/a/43103038/5155923 and > http://openjdk.java.net/jeps/247) which makes using animal-sniffer-plugin > obsolete with JDK9. > > I would therefore recommend to configure javac via the "release" parameter > (supported since m-c-p 3.6.0, see > https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release). > Maybe we should do that in a profile only activated for Java9 and above. > The animal-sniffer-plugin should only be used for Java < 9. > > I think with those conclusions we can again get rid of your custom plugin and > only use the buildhelper-plugin to determine the right animal sniffer > signature version when running in Java < 9. > WDYT? > >> On 4. Sep 2017, at 14:01, Robert Munteanu wrote: >> >> On Mon, 2017-09-04 at 13:06 +0200, Konrad Windszus wrote: Am 04.09.2017 um 11:30 schrieb Robert Munteanu : > On Mon, 2017-09-04 at 08:55 +0200, Konrad Windszus wrote: > If I understand correctly we only need to extract the relevant > version from the sling java property and use that then in the > configuration of other plugins (like animal sniffer or m-c-p). > That > is totally possible with the mentioned buildhelper plugin. Agreed. > There is no need for a dedicated plugin. The BREE header is > mostly > static and must be set in the m-b-p configuration. The dynamic > part > can also be retrieved via the buildhelper plugin. I hope this > makes > things clearer. The BREE header is set following the sling.java.version property. Yes, it is mostly static but does not directly follow the Java version ( see [1] for more details). Here is a mapping of sling.java.version to BREE headers: 5 - J2SE-1.5 6 - JavaSE-1.6 7 - JavaSE-1.7 8 - JavaSE-1.8 9 - JavaSE-9 This is something that we mapped with the antrun plugin stuff. Now I propose switching to a custom plugin due to Java 9 issues. I still don't see how the BREE header can be configured using the buildhelper plugin. Can you add a small config snippet or link to an example? >>> >>> Supporting Java5 is probably not necessary and even for Java 9 >>> JavaSE-1.9 seems valid. >> >> Seems, but it is not :-) >> >> I started the Sling launchpad with Java 9 and the system bundle >> provides the following capabilities: >> >> osgi.ee; osgi.ee="OSGi/Minimum"; version:List="1.0, 1.1, 1.2", osgi.ee; >> osgi.ee="JavaSE"; version:List="1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, >> 1.8, 9", >> osgi.ee; osgi.ee="JavaSE/compact1"; version:List="1.8, 9", >> osgi.ee; osgi.ee="JavaSE/compact2"; version:List="1.8, 9", >> osgi.ee; osgi.ee="JavaSE/compact3"; version:List="1.8, 9" >> >> Note the 9 everywhere, following the version change in Java: >> >> $ /opt/jdk-9/bin/java -version >> java version "9" >> (snip) >> >>> I think you can generate the header then with the following bnd >>> instruction: http://bnd.bndtools.org/instructions/runee.html >> >> The way I read it, this instruction parses a string argument into an EE >> enum. That does not help us as we are using a 'plain' java version >> string, not a legal execution environment value. >> >> - >> >> I understand the desire to not reinvent the wheel, especially with >> infrastructure code. However, releasing this plugin unblocks us with >> testing for Java 9, which has further issues once we run the ITs. >> >> Releasing a version of this plugin does not mean we'll never revisit >> the solution. If there is something better, I'm happy to remove the >> plugin from our parent pom. But given that the code is there, it's >> small and self-contained I'm inclined just to use it for now, and when >> we have a better solution retire it. >> >> Thanks, >> >> Robert >> >>> Thanks, Robert [1]: https://www.osgi.org/developer/specifications/reference/ > > Von meinem iPhone gesendet > >> Am 03.09.2017 um 23:01 schrie
[jira] [Resolved] (SLING-7126) add not pipe in pipebuilder
[ https://issues.apache.org/jira/browse/SLING-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Peltier resolved SLING-7126. Resolution: Fixed Assignee: Nicolas Peltier Fix Version/s: pipes 1.1.0 > add not pipe in pipebuilder > --- > > Key: SLING-7126 > URL: https://issues.apache.org/jira/browse/SLING-7126 > Project: Sling > Issue Type: Improvement > Components: Extensions >Affects Versions: Pipes 1.0.4 >Reporter: Nicolas Peltier >Assignee: Nicolas Peltier > Fix For: pipes 1.1.0 > > > add not pipe in pipebuilder -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168184#comment-16168184
]
Justin Edelson commented on SLING-7124:
---
Good point [~kwin]. Added this log message:
{code}
251 [main] DEBUG org.apache.sling.models.impl.ModelAdapterFactory -
PostConstruct method
org.apache.sling.models.testmodels.classes.FalsePostConstuctModel.pc returned
false. Returning null model.
{code}
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-3228) PostServletPrivilegesUpdateTest integration test fails with Oak, needs test categories
[ https://issues.apache.org/jira/browse/SLING-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168116#comment-16168116 ] Konrad Windszus commented on SLING-3228: [~rombert] Since you integrated Jackrabbit 2.14.3 in SLING-7102 could we reenable the tests now? > PostServletPrivilegesUpdateTest integration test fails with Oak, needs test > categories > -- > > Key: SLING-3228 > URL: https://issues.apache.org/jira/browse/SLING-3228 > Project: Sling > Issue Type: Bug > Components: Testing >Reporter: Bertrand Delacretaz >Assignee: Robert Munteanu >Priority: Minor > Labels: sling-IT > > The PostServletPrivilegesUpdateTest test fails on Oak, it expects a property > added event that Oak doesn't supply. > This is a good opportunity to implement the SLING-3151 test categories, we > can then keep both tests so as to document the subtle differences between Oak > and Jackrabbit when it comes to JCR events. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7124) Allow PostConstruct method to return false to indicate that a model object should not be returned
[
https://issues.apache.org/jira/browse/SLING-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168094#comment-16168094
]
Konrad Windszus commented on SLING-7124:
Please add at least some logging with level DEBUG in case {{false}} has been
returned. Otherwise it is close to impossible to trace afterwards why a model
could not be retrieved. IMHO we must pay attention that Sling Model issues
don't get even more complicated to debug during development time.
> Allow PostConstruct method to return false to indicate that a model object
> should not be returned
> -
>
> Key: SLING-7124
> URL: https://issues.apache.org/jira/browse/SLING-7124
> Project: Sling
> Issue Type: Improvement
> Components: Extensions
>Reporter: Justin Edelson
> Attachments: SLING-7124.diff
>
>
> In cases where a model objects (as opposed to the adaptable Resources) need
> to be validated programmatically, the options at present are to have the
> PostConstruct method throw an Exception or to have a special method which
> clients use to determine if the object is valid. The former adds unnecessary
> noise to the log files and the latter puts undue complexity on clients.
> It should be possible to return {{false}} from the PostConstruct method and
> for this to be considered a signal for a null value to be returned from the
> adaptTo() method (without extra logging). For the createModel() cases, we
> can't return null and have to throw an exception.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SLING-5739) [Sling Models] Allow for extensible @Via providers
[
https://issues.apache.org/jira/browse/SLING-5739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16168089#comment-16168089
]
Konrad Windszus commented on SLING-5739:
[~justinedelson] Can you update the documentation at
https://sling.apache.org/documentation/bundles/models.html#via for this feature
and also document the shipped Via providers?
> [Sling Models] Allow for extensible @Via providers
> --
>
> Key: SLING-5739
> URL: https://issues.apache.org/jira/browse/SLING-5739
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
>Reporter: Justin Edelson
>Assignee: Justin Edelson
> Attachments: SLING-5739.diff
>
>
> Currently, @Via support in Sling Models is limited to JavaBean properties. It
> would be useful to be able to extend this and allow for downstream projects
> to add new @Via providers.
> Proposing to support this by extending the @Via annotation
> {code}
> @Via(value = "jcr:content", type = ChildResource.class)
> {code}
> The default type is BeanProperty (the current behavior).
> New providers can be added by implementing a ViaProvider SPI and provide a
> marker class for use in the annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.14, Apache Sling Scripting HTL Java Compiler 1.0.14, Apache Sling Scripting HTL Engine 1.0.42
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Resolved] (SLING-7103) Authentication-related test failures on Java 9
[
https://issues.apache.org/jira/browse/SLING-7103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-7103.
Resolution: Cannot Reproduce
Assignee: Robert Munteanu
Failures no longer seen on any of the IT jobs.
> Authentication-related test failures on Java 9
> --
>
> Key: SLING-7103
> URL: https://issues.apache.org/jira/browse/SLING-7103
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Launchpad Testing 9
>
>
> A number of ITs fail, namely:
> {noformat}Tests run: 8, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.086 sec <<< FAILURE! - in
> org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest
> testAnonymousSelfRegistrationDisabled(org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest)
> Time elapsed: 0.006 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<500> but was:<401>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.Assert.assertEquals(Assert.java:241)
> at junit.framework.TestCase.assertEquals(TestCase.java:409)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.assertPostStatus(HttpTestBase.java:410)
> at
> org.apache.sling.launchpad.webapp.integrationtest.userManager.CreateUserTest.testAnonymousSelfRegistrationDisabled(CreateUserTest.java:211){noformat}
> {noformat}Running
> org.apache.sling.launchpad.webapp.integrationtest.login.AuthRequestLoginTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec <<<
> FAILURE! - in
> org.apache.sling.launchpad.webapp.integrationtest.login.AuthRequestLoginTest
> testForcedLogin(org.apache.sling.launchpad.webapp.integrationtest.login.AuthRequestLoginTest)
> Time elapsed: 0.004 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Expected status 200 for
> http://localhost:41000/system/sling/info.sessionInfo.json (content=)
> expected:<200> but was:<401>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.assertEquals(TestCase.java:401)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:457)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:432)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:424)
> at
> org.apache.sling.commons.testing.integration.HttpTestBase.getContent(HttpTestBase.java:419)
> at
> org.apache.sling.launchpad.webapp.integrationtest.login.AuthRequestLoginTest.testForcedLogin(AuthRequestLoginTest.java:40)
> Running
> org.apache.sling.launchpad.webapp.integrationtest.login.RedirectOnLogoutTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec <<<
> FAILURE! - in
> org.apache.sling.launchpad.webapp.integrationtest.login.RedirectOnLogoutTest
> testRedirectToResourceAfterLogout(org.apache.sling.launchpad.webapp.integrationtest.login.RedirectOnLogoutTest)
> Time elapsed: 0.014 sec <<< FAILURE!
> java.lang.AssertionError: Expected redirect expected:<302> but was:<401>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.sling.launchpad.webapp.integrationtest.login.RedirectOnLogoutTest.testRedirectToResourceAfterLogout(RedirectOnLogoutTest.java:70)
> Running
> org.apache.sling.launchpad.webapp.integrationtest.login.AnonymousAccessTest
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec <<<
> FAILURE! - in
> org.apache.sling.launchpad.webapp.integrationtest.login.AnonymousAccessTest
> testAnonymousContent(org.apache.sling.launchpad.webapp.integrationtest.login.AnonymousAccessTest)
> Time elapsed: 0.012 sec <<< FAILURE!
> junit.framework.AssertionFailedError: Expected status 200 for
> http://localhost:41000/AnonymousAccessTest/1504552511132/test_text_1504552511.txt
> (content=) expected:<200> but was:<401>
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.Assert.assertEquals(Assert.java:234)
> at junit.framework.TestCase.as
[jira] [Updated] (SLING-7127) slingstart-maven-plugin should respect JAVA_HOME when set
[ https://issues.apache.org/jira/browse/SLING-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7127: --- Fix Version/s: (was: Slingstart Maven Plugin 1.7.8) Slingstart Maven Plugin 1.7.10 > slingstart-maven-plugin should respect JAVA_HOME when set > - > > Key: SLING-7127 > URL: https://issues.apache.org/jira/browse/SLING-7127 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Robert Munteanu >Assignee: Robert Munteanu > Fix For: Slingstart Maven Plugin 1.7.10 > > > The typical way of configuring a different Java binary to use is by setting > the JAVA_HOME environment variable. This allows for instance using a > different JVM version than the default one. > The slingstart-maven-plugin ( in LauncherCallable ) unconditionally uses > 'java' as the command name. We should allow for a custom JAVA_HOME to be set. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7128) slingstart-maven-plugin should respect JAVA_HOME when set
[ https://issues.apache.org/jira/browse/SLING-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-7128. Resolution: Fixed Fixed in [r1808449|https://svn.apache.org/r1808449] > slingstart-maven-plugin should respect JAVA_HOME when set > - > > Key: SLING-7128 > URL: https://issues.apache.org/jira/browse/SLING-7128 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Robert Munteanu >Assignee: Robert Munteanu > Fix For: Slingstart Maven Plugin 1.7.10 > > > The typical way of configuring a different Java binary to use is by setting > the JAVA_HOME environment variable. This allows for instance using a > different JVM version than the default one. > The slingstart-maven-plugin ( in LauncherCallable ) unconditionally uses > 'java' as the command name. We should allow for a custom JAVA_HOME to be set. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (SLING-7128) slingstart-maven-plugin should respect JAVA_HOME when set
[ https://issues.apache.org/jira/browse/SLING-7128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7128: --- Fix Version/s: (was: Slingstart Maven Plugin 1.7.8) Slingstart Maven Plugin 1.7.10 > slingstart-maven-plugin should respect JAVA_HOME when set > - > > Key: SLING-7128 > URL: https://issues.apache.org/jira/browse/SLING-7128 > Project: Sling > Issue Type: Improvement > Components: Maven Plugins and Archetypes >Reporter: Robert Munteanu >Assignee: Robert Munteanu > Fix For: Slingstart Maven Plugin 1.7.10 > > > The typical way of configuring a different Java binary to use is by setting > the JAVA_HOME environment variable. This allows for instance using a > different JVM version than the default one. > The slingstart-maven-plugin ( in LauncherCallable ) unconditionally uses > 'java' as the command name. We should allow for a custom JAVA_HOME to be set. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7128) slingstart-maven-plugin should respect JAVA_HOME when set
Robert Munteanu created SLING-7128: -- Summary: slingstart-maven-plugin should respect JAVA_HOME when set Key: SLING-7128 URL: https://issues.apache.org/jira/browse/SLING-7128 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Slingstart Maven Plugin 1.7.8 The typical way of configuring a different Java binary to use is by setting the JAVA_HOME environment variable. This allows for instance using a different JVM version than the default one. The slingstart-maven-plugin ( in LauncherCallable ) unconditionally uses 'java' as the command name. We should allow for a custom JAVA_HOME to be set. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SLING-7127) slingstart-maven-plugin should respect JAVA_HOME when set
Robert Munteanu created SLING-7127: -- Summary: slingstart-maven-plugin should respect JAVA_HOME when set Key: SLING-7127 URL: https://issues.apache.org/jira/browse/SLING-7127 Project: Sling Issue Type: Improvement Components: Maven Plugins and Archetypes Reporter: Robert Munteanu Assignee: Robert Munteanu Fix For: Slingstart Maven Plugin 1.7.8 The typical way of configuring a different Java binary to use is by setting the JAVA_HOME environment variable. This allows for instance using a different JVM version than the default one. The slingstart-maven-plugin ( in LauncherCallable ) unconditionally uses 'java' as the command name. We should allow for a custom JAVA_HOME to be set. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: [git] Naming of git repositories
On Fri, 2017-09-08 at 22:40 +0200, Oliver Lietz wrote:
> On Friday 08 September 2017 16:48:24 Stefan Seifert wrote:
> > in our last discussion [1] our plan was this:
> >
> >
> > > - name pattern for the git repository should be something like
> > > "sling-"
>
> - we drop the folder grouping from svn today in
> > > "extensions", "servlets", "commons" etc. only the hierarchy of
> > > artifactId
> > > is relevant. - with the prefix "sling-" they
> > > - question: how are "contrib" and "samples" repos marked? by
> > > another
> > > prefix like "sling-contrib-" and "sling-samples-"?
> >
> > i'm in favor of using the artifactid because it's unique and easy
> > to find.
>
> +1 for artifactId (with prefix sling if really required – we only
> have four
> maintained artifacts without sling) because it's a dead simple
> pattern (for
> automation also).
Seems that everyone else seem to like the artifact id so we'll go with
that.
Thanks for the input.
Robert
>
> O.
>
> > stefan
> >
> > [1]
> > https://lists.apache.org/thread.html/37765304556b17a04e7eb122afd895
> > ea7beae9
> > 57d56c9d4501a9f2e0@%3Cdev.sling.apache.org%3E
>
>
> >
> >
> > > -Original Message-
> > > From: Robert Munteanu [mailto:romb...@apache.org]
> > > Sent: Friday, September 8, 2017 3:34 PM
> > > To: dev@sling.apache.org
> > > Subject: [git] Naming of git repositories
> > >
> > > Hi,
> > >
> > > I've started thinking a bit about the Git migration process. I
> > > don't
> > > think we've discussed naming individual Sling modules after being
> > > extracted from SVN.
> > >
> > > ASF mandates that we use a pattern of 'TLP-module' for the git
> > > repositories, so the modules must be name sling-${something}.
> > >
> > > As for that ${something}, it can be one of
> > >
> > > 1. artifactId / Bundle-SymbolicName
> > > 2. short name ( as currently used in the SVN repo )
> > >
> > > I would favour option 2, as I think option 1 has too much
> > > redundancy:
> > >
> > >
> > > sling-org.apache.sling.auth.core
> > >
> > >
> > > is too verbose compared to
> > >
> > >
> > > sling-auth-core
> > >
> > >
> > >
> > > Refining option #2, we should remove some commons prefixes, such
> > > as:
> > >
> > > - bundles
> > > - contrib/bundles
> > > - bundles/extensions
> > > - contrib
> > > - contrib/extensions
> > > - karaf
> > > - tooling/maven
> > >
> > > Thoughts?
> > >
> > > Robert
> >
> >
>
>
[jira] [Commented] (SLING-7061) Access control setup of repository-level permissions (i.e. null path)
[ https://issues.apache.org/jira/browse/SLING-7061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16167599#comment-16167599 ] Timothee Maret commented on SLING-7061: --- Skimming through the JavaCC [doc|https://javacc.org/tutorials/tokenmanager], the parsing order is kept from the input file. Also, the parser unit tests implicitly test the parsing order. > Access control setup of repository-level permissions (i.e. null path) > - > > Key: SLING-7061 > URL: https://issues.apache.org/jira/browse/SLING-7061 > Project: Sling > Issue Type: Improvement > Components: Repoinit >Affects Versions: Repoinit Parser 1.1.0 >Reporter: angela >Assignee: Timothee Maret > Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6 > > > If I am not mistaken it is currently not possible to create access control > setup for principals at the 'null' path, which according to JSR 283 is to be > used to setup repository level permissions such as > - node type definition management (i.e. registering new node types) > - namespace management (i.e. registering new namespaces) > - privilege management (i.e. registering new privileges) > - workspace management (i.e. creating/removing workspaces) > All of these operations are not bound to a path (like e.g. removing an item > or creating a new version for a given node) but instead take global effect on > the whole JCR repository... that's why permissions for these operations > cannot be granted at a given path. > In the default authorization model shipped with Jackrabbit and Oak the -null- > path access control policy is stored with a dedicated _rep:repoPolicy_ node > located with the root node and > For service user definitions we need to be able to define entries for the > -null- path policy for the reasons explained above. Thanks for extending the > repo-init accordingly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (SLING-7066) Support mixins in repoinit "create path" statements
[
https://issues.apache.org/jira/browse/SLING-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothee Maret resolved SLING-7066.
---
Resolution: Fixed
Fix Version/s: Repoinit JCR 1.1.6
Repoinit Parser 1.1.2
> Support mixins in repoinit "create path" statements
> ---
>
> Key: SLING-7066
> URL: https://issues.apache.org/jira/browse/SLING-7066
> Project: Sling
> Issue Type: New Feature
> Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Timothee Maret
>Priority: Minor
> Fix For: Repoinit Parser 1.1.2, Repoinit JCR 1.1.6
>
>
> The repoinit "create path" statement currently supports nodetypes but no
> mixins, we should add support for them.
> The current create path syntax is like
> {code}
> create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
> create path /one/two/three
> create path /three/four(nt:folk)/five(nt:jazz)/six
> {code}
> Where the first bracketed statement, before the path, is the default nodetype
> for all subpaths, and each subpath can have a specific nodetype.
> To add mixin support I suggest the syntax of these examples for these
> bracketed statements:
> {code}
> (sling:Folder mixin mix:A, mix:B)
> (nt:unstructured mixin mix:C)
> (mixin mix:A)
> (mixin mix:A, mix:B)
> {code}
> The last two forms without a nodeteype meaning "set mixins only but keep the
> default nodetype", which in this example
> {code}
> create path (sling:Folder) /var/foo(mixin mix:B)
> {code}
> means /var/foo is of type sling:Folder with mixin mix:B
> whereas in this example
> {code}
> create /var/bar(mixin mix:C)
> {code}
> /var/bar uses the default type defined by /var's type, with mix:C added.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: [VOTE] Release Apache Sling Scripting HTL Compiler 1.0.14, Apache Sling Scripting HTL Java Compiler 1.0.14, Apache Sling Scripting HTL Engine 1.0.42
On Fri, 2017-09-15 at 07:41 +, Radu Cotescu wrote: > Please vote to approve this release: +1 Robert signature.asc Description: This is a digitally signed message part
[jira] [Commented] (SLING-7066) Support mixins in repoinit "create path" statements
[
https://issues.apache.org/jira/browse/SLING-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16167545#comment-16167545
]
Timothee Maret commented on SLING-7066:
---
Added example in the documentation at http://svn.apache.org/r1808435
> Support mixins in repoinit "create path" statements
> ---
>
> Key: SLING-7066
> URL: https://issues.apache.org/jira/browse/SLING-7066
> Project: Sling
> Issue Type: New Feature
> Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Timothee Maret
>Priority: Minor
>
> The repoinit "create path" statement currently supports nodetypes but no
> mixins, we should add support for them.
> The current create path syntax is like
> {code}
> create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
> create path /one/two/three
> create path /three/four(nt:folk)/five(nt:jazz)/six
> {code}
> Where the first bracketed statement, before the path, is the default nodetype
> for all subpaths, and each subpath can have a specific nodetype.
> To add mixin support I suggest the syntax of these examples for these
> bracketed statements:
> {code}
> (sling:Folder mixin mix:A, mix:B)
> (nt:unstructured mixin mix:C)
> (mixin mix:A)
> (mixin mix:A, mix:B)
> {code}
> The last two forms without a nodeteype meaning "set mixins only but keep the
> default nodetype", which in this example
> {code}
> create path (sling:Folder) /var/foo(mixin mix:B)
> {code}
> means /var/foo is of type sling:Folder with mixin mix:B
> whereas in this example
> {code}
> create /var/bar(mixin mix:C)
> {code}
> /var/bar uses the default type defined by /var's type, with mix:C added.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SLING-7119) Add configurator support for the Jackrabbit filevault-package-maven-plugin
[ https://issues.apache.org/jira/browse/SLING-7119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-7119: --- Summary: Add configurator support for the Jackrabbit filevault-package-maven-plugin (was: Add configurator support for the Jackrabbit package-maven-plugin) > Add configurator support for the Jackrabbit filevault-package-maven-plugin > -- > > Key: SLING-7119 > URL: https://issues.apache.org/jira/browse/SLING-7119 > Project: Sling > Issue Type: Improvement > Components: IDE >Reporter: Robert Munteanu > Fix For: Sling Eclipse IDE 1.2.0 > > > Once the first release of the Jackrabbit package-maven-plugin is out, we > should add configurator support for it. > See JCRVLT-202 for details. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SLING-7066) Support mixins in repoinit "create path" statements
[
https://issues.apache.org/jira/browse/SLING-7066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16167529#comment-16167529
]
Timothee Maret commented on SLING-7066:
---
Commit at http://svn.apache.org/r1808431
> Support mixins in repoinit "create path" statements
> ---
>
> Key: SLING-7066
> URL: https://issues.apache.org/jira/browse/SLING-7066
> Project: Sling
> Issue Type: New Feature
> Components: Repoinit
>Reporter: Bertrand Delacretaz
>Assignee: Timothee Maret
>Priority: Minor
>
> The repoinit "create path" statement currently supports nodetypes but no
> mixins, we should add support for them.
> The current create path syntax is like
> {code}
> create path (sling:Folder) /var/discovery(nt:unstructured)/somefolder
> create path /one/two/three
> create path /three/four(nt:folk)/five(nt:jazz)/six
> {code}
> Where the first bracketed statement, before the path, is the default nodetype
> for all subpaths, and each subpath can have a specific nodetype.
> To add mixin support I suggest the syntax of these examples for these
> bracketed statements:
> {code}
> (sling:Folder mixin mix:A, mix:B)
> (nt:unstructured mixin mix:C)
> (mixin mix:A)
> (mixin mix:A, mix:B)
> {code}
> The last two forms without a nodeteype meaning "set mixins only but keep the
> default nodetype", which in this example
> {code}
> create path (sling:Folder) /var/foo(mixin mix:B)
> {code}
> means /var/foo is of type sling:Folder with mixin mix:B
> whereas in this example
> {code}
> create /var/bar(mixin mix:C)
> {code}
> /var/bar uses the default type defined by /var's type, with mix:C added.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[VOTE] Release Apache Sling Scripting HTL Compiler 1.0.14, Apache Sling Scripting HTL Java Compiler 1.0.14, Apache Sling Scripting HTL Engine 1.0.42
Hi, We solved 1 issue in these releases: https://issues.apache.org/jira/projects/SLING/versions/12341616 https://issues.apache.org/jira/projects/SLING/versions/12341617 https://issues.apache.org/jira/projects/SLING/versions/12341618 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-1785 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 1785 /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, Radu
