[jira] [Resolved] (SLING-6943) Don't call into service registry from within a synchronized block

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6943.
-
Resolution: Fixed
  Assignee: Carsten Ziegeler

Applied the patch in rev f2f1bc2

> Don't call into service registry from within a synchronized block
> -
>
> Key: SLING-6943
> URL: https://issues.apache.org/jira/browse/SLING-6943
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Resource Resolver 1.5.32
>
> Attachments: SLING-6943.patch
>
>
> ResourceProviderTracker activates and deactivates resource providers within a 
> synchronized block which then calls get/unget service on the service registry.
> I think we should avoid doing these calls within a sync'ed block



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (SLING-7264) Switch to OSGi annotation

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra edited comment on SLING-7264 at 11/24/17 5:58 AM:
--

Did changes with 
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=d39cc33a8788c2c6b71dd798cfc0a514cf37bd85]

[~cziegeler] Can you review the commit once? I had to add dummy methods for 
bindLog and unbindLog as otherwise the log service was not getting bound i.e. 
parent methods were not getting invoked


was (Author: chetanm):
Did changes with 
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=d39cc33a8788c2c6b71dd798cfc0a514cf37bd85]

> Switch to OSGi annotation 
> --
>
> Key: SLING-7264
> URL: https://issues.apache.org/jira/browse/SLING-7264
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Registration 1.0.4
>
>
> Switch to official OSGi annotations



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7264) Switch to OSGi annotation

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-7264:


Did changes with 
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=d39cc33a8788c2c6b71dd798cfc0a514cf37bd85]

> Switch to OSGi annotation 
> --
>
> Key: SLING-7264
> URL: https://issues.apache.org/jira/browse/SLING-7264
> Project: Sling
>  Issue Type: Task
>  Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Registration 1.0.4
>
>
> Switch to official OSGi annotations



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7264) Switch to OSGi annotation

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-7264:
--

 Summary: Switch to OSGi annotation 
 Key: SLING-7264
 URL: https://issues.apache.org/jira/browse/SLING-7264
 Project: Sling
  Issue Type: Task
  Components: JCR
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: JCR Registration 1.0.4


Switch to official OSGi annotations



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Sling Tooling IDE and IntelliJ

[Andreas Schaefer]

Hi Robert

See my notes inlined:

> On Nov 22, 2017, at 1:25 AM, Robert Munteanu  wrote:
> 
> Hi Andreas,
> 
> On Tue, 2017-11-21 at 15:42 -0800, Andreas Schaefer wrote:
>> Hi
>> 
>> Last and this year I am working on a IntelliJ Plugin to help develop
>> Sling / AEM
>> projects. Since the start I ran into issue with the Sling Tooling IDE
>> code base
>> as the code is geared towards Eclipse and its use of OSGi. Despite
>> several
>> tries to come up with a resolution to create a code base that would
>> work equally
>> all for IntelliJ and Eclipse there was not progress made towards a
>> solution.
> 
> Yes, I am aware of that :-( I still don't have a good answer on how to
> build AEM and IntelliJ plugins together. If you have examples or ideas
> how to do that I'd be happy to work towards that goal.
> 
> The idea would be simple: allow plain Maven artifacts to be consumed by
> both an IntelliJ Maven build and an Eclipse Maven build. This is
> currently complicated due to the Tycho/p2 implementation which requires
> p2 update sites over http.

There are a few things that I needs to be done:

1. Make common code like impl-vlt eclipse agnostic. If you want or need
an Activator / Logger then we can create an interface and then you wrap
this in an eclipse module.

2. Shared code that interacts with the IDE needs to be written in a way
that each plugin can extend or delegate it and the common code is left
in a non-eclipse module. IntelliJ right now uses a class that contains common
IDE code and its access to the remote server. Then IntelliJ plugin is
extending that class providing the integration with IntelliJ.

I would be willing to create the same wrapper for Eclipse if someone can
show where to find the necessary Eclipse code like IServer, IFile etc and 
the implementation of it. I tried to find it but could not find in a reasonable
amount of time.

> 
>> 
>> That said since then there are other issues that came up which make
>> developing
>> and using an Plugin difficult:
>> 
>> 1. There is no support for developing and deploying parts of a Sling
>> Content Bundle
>> as the only way to deploy content is building and deploying the
>> bundle.
> 
> What do you mean by Content Bundle? If you are talking about bundles
> using the content loader [1], then support is there for deployment.
> When a bundle is deployed, all output resources should be gathered in
> the output directory and the proper manifest generated. The only
> limitation I'm aware of is while working in debug mode [2].

Ok, I will take a Content Bundle and test that.

> 
> 
>> 2. IntelliJ (and I assume Eclipse) Plugin cannot import resources
>> from Sling / AEM
>> from a Sling Content Bundle
> 
> With the same understanding of content bundles, we only support content
> packages. That was the pattern we saw most used developing AEM and
> Sling apps, and that is the one we support right now.

If my content is stored in a SLING-INF folder can I import a resource
from Sling using the plugin?

> 
>> 
>> 3. IntelliJ and Sling (AFAIK) do not support OSGi bundle deployment
>> as part of a
>> JCR Package which can lead to problems with OSGi bundles in Sling
>> (not sure about
>> AEM). This is an general issue with embedded bundles when they are
>> deployed
>> both as embedded and standalone archive.
> 
> I'm curious, why would you want to deploy an OSGi bundle when working
> on a content package? I would rather configure them as bundle modules
> and allow deployment to work independently of content packages.
> 
> Is it only because the bundle is deployed by both the JCR installer and
> then also via the Web Console? If so, I'd like to hear some examples of
> what goes wrong, to see if we can fix them or work around them.

Having my bundles embedded inside a Content Package is to make sure
that both are in sync. For example if I updated my page (resource) as well
as the Sling Model it uses then I can deploy it together. 

I installed Eclipse Oxygen, the latest from Sling (Git) and started it. Then
I took a sling project that has a core (OSGi bundle) and an ui.apps that
has the core embedded but also contains resources. When I deploy this
manually (via Maven) then any updates to the core bundle will not be
taken effect in Sling until I deploy it again from Maven.

This is AFAIK due to the fact that the bundle from the package overrides
any deployments directly to the OSGi container and this is also a problem
if someone deploys the bundle manually or through bundle deployment
tool after a JCR package with that bundle is deployed.

A plugin should be able to deploy the bundle as part of the package
from within the plugin if embedded bundles are supported in Sling.

> 
>> 
>> 
>> This list makes me think that the Sling Tooling IDE module is not
>> actively developed
>> anymore. Please let me know what you plans are so we can adjust it on
>> our end.
> 
> The IDE tooling is actively developed, just not at the pace it used to
> be. Most 'core' 

[jira] [Commented] (SLING-6943) Don't call into service registry from within a synchronized block

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6943:
---

[~cziegeler], where are we with this issue - I would like to do a release 
hence, can we push it?

> Don't call into service registry from within a synchronized block
> -
>
> Key: SLING-6943
> URL: https://issues.apache.org/jira/browse/SLING-6943
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
>Reporter: Carsten Ziegeler
> Fix For: Resource Resolver 1.5.32
>
> Attachments: SLING-6943.patch
>
>
> ResourceProviderTracker activates and deactivates resource providers within a 
> synchronized block which then calls get/unget service on the service registry.
> I think we should avoid doing these calls within a sync'ed block



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7252) ResourceResolverImpl.map() does not invoke ResourceDecorator

[Karl Pauls (JIRA)]

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

Karl Pauls resolved SLING-7252.
---
Resolution: Fixed

I applied the patch in:

0ddea42449200239f972ac64c07abe8110e688a6

many thanks!

> ResourceResolverImpl.map() does not invoke ResourceDecorator
> 
>
> Key: SLING-7252
> URL: https://issues.apache.org/jira/browse/SLING-7252
> Project: Sling
>  Issue Type: Bug
>  Components: ResourceResolver
>Affects Versions: Resource Resolver 1.4.16, Resource Resolver 1.5.30
>Reporter: Francisco Chicharro
>Assignee: Karl Pauls
> Fix For: Resource Resolver 1.5.32
>
> Attachments: resourceresolverimpl.patch
>
>
> ResourceDecorators are invoked by ResourceResolverImpl for resource 
> resolution but not for mapping.
> I'm experiencing this issue with version 1.4.16, but the issue is also there 
> for latest version 1.5.30.
> I'm attaching a patch for 1.4.16 version.
> CC: [~cziegeler]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Starter Startup 1.0.4

[Karl Pauls]

+1

regards,

Karl

On Thu, Nov 23, 2017 at 9:30 AM, Robert Munteanu  wrote:
> On Wed, 2017-11-22 at 16:25 +, Radu Cotescu wrote:
>> Please vote to approve this release:
>
> +1
>
> Robert



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-7157:
-

[~chetanm] We definitely should fix the metatype bug before a release. I think 
the best option is to move to the new annotations, it seems you were looking at 
an old official Component annotation. The one from R6 (version 1.3) has a 
references attribute. I think the other option is to use the latest maven scr 
plugin which generates correct metatype info, however that one doesn't work on 
windows.

> metatype.properties file must not be in OSGI-INF/metatype
> -
>
> Key: SLING-7157
> URL: https://issues.apache.org/jira/browse/SLING-7157
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Web Console 1.0.2, JCR Registration 1.0.2, JCR 
> ClassLoader 3.2.2, Form Based Authentication 1.0.8, Settings 1.3.8, Commons 
> Threads 3.2.6, Auth Core 1.4.0, SLF4J MDC Filter 1.0.0, Authentication XING 
> OAuth 0.0.2, Authentication XING Login 0.0.2, URL Rewriter 0.0.2, DataSource 
> Provider 1.0.4, NoSQL MongoDB Resource Provider 1.1.0, Commons Log 5.0.2, 
> Discovery Impl 1.2.12, Discovery Oak 1.2.18, JCR Davex 1.3.8, JCR Webdav 
> 2.3.8, JCR Installer 3.1.26
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: JCR Web Console 1.0.4, JCR Registration 1.0.4, JCR 
> ClassLoader 3.2.4, Form Based Authentication 1.0.10, Settings 1.3.10, Auth 
> Core 1.4.2, Mongo Resource Provider 1.0.0, Authentication XING OAuth 0.0.4, 
> Authentication XING Login 0.0.4, DataSource Provider 1.0.4, URL Rewriter 
> 0.0.4, Commons Log 5.0.4, Commons Threads 3.2.10, SLF4J MDC Filter 1.0.2, JCR 
> Webdav 2.3.10, JCR Installer 3.1.28, Discovery Impl 1.2.14, Discovery Oak 
> 1.2.24, JCR Davex 1.3.12
>
>
> According to the spec the metatype.properties file must not be inside the 
> OSGI-INF/metatype directory. This is against the spec, so we should move it 
> to OSGI-INF/l10n
> We probably should also upgrade the maven-scr-plugin for this 1.25.0
> I found the following files:
> ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/startup-filter/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/urlrewriter/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./installer/providers/jcr/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./samples/path-based-rtp/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./samples/workspacepicker/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./testing/junit/core/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./testing/junit/healthcheck/src/main/resources/OSGI-INF/metatype/metatype.properties



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Moving org-apache-sling-commons-cache-portal to the whiteboard (was: Is anyone looking into org.apache.sling.portal.container?)

[Robert Munteanu]

On Thu, 2017-11-16 at 14:04 -0800, Carsten Ziegeler wrote:
> I didn't even know we have such a cache module :)
> 
> I don't think we should move the portal stuff out of the whiteboard,
> I
> would rather move the cache to the whiteboard as well.

Agreed. Does anyone object on moving the current org-apache-sling-
commons-cache-portal to the whiteboard? I'll take care of moving the
portal stuff from SVN to the Git whiteboard, so they're all in one
place.

Thanks,

Robert

[jira] [Commented] (SLING-7262) Generate reusable list of repositories for machine consumption

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-7262:


You're welcome! I have now also added a {{OncePerBuild}} mechanism that we 
might use to create that modules json file, I think it's cleaner than having an 
additional Maven setup?

The code that talks to Git should not run if the json file already exists, to 
avoid slowing down interactive staging.

See commit https://github.com/apache/sling-site/commit/03c78d0

I'm not planning to implement the Git -> json code now but that should make it 
easy for you to adapt what you have in your prototype.

> Generate reusable list of repositories for machine consumption
> --
>
> Key: SLING-7262
> URL: https://issues.apache.org/jira/browse/SLING-7262
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Robert Munteanu
>
> We currently have two 'clients' that query the github repos and the 
> .sling-module.xml descriptors:
> * the jenkins job creation DSL script
> * the repo manifest creation script
> We've also discussed in SLING-7161 the possibility of listing all 
> repositories on the website.
> To minimize the effort of talking to github in each location and reduce the 
> number of calls to Github ( for rate limiting purposes ) we should generate a 
> JSON/XML file that contains all information about the git repos. This file is 
> in turns read by various "clients" that need the information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7183) Update old 'sling' github mirror to reflect Git migration

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7183:


Current consensus seems to be:

- rename to _sling-old-svn-mirror_
- change default branch to _archived_

> Update old 'sling' github mirror to reflect Git migration
> -
>
> Key: SLING-7183
> URL: https://issues.apache.org/jira/browse/SLING-7183
> Project: Sling
>  Issue Type: Sub-task
>  Components: Best practices
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> We had some long discussions on the dev@list ( see for instance [What to do 
> with 
> github.com/apache/sling|https://lists.apache.org/thread.html/3cd73a6b55423e07424fae54fead688e854f190ee8309257e13a1381@%3Cdev.sling.apache.org%3E]
>  and came to the conclusion that we can't delete the old sling github mirror. 
> If we do that, all links to commits and pull requests would be broken. A 
> couple of ideas were circulated:
> - change the default branch to archived and add only a README file ( the 
> branch exists, but default was not changed - 
> https://github.com/apache/sling/tree/archived )
> - delete the contents of the trunk branch and leave just a README ; also tag 
> the last state of trunk to keep the commits around ( this breaks links that 
> include 'trunk' though )
> - rename the repo to sling-something-else ; git will generate redirects
> For whatever we decided to do we need to decide first and then ask infra for 
> assistance - we can't change the git repo setup ourselves.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [git] Retiring the old github.com/sling project

[Robert Munteanu]

On Thu, 2017-11-23 at 12:59 +0100, Bertrand Delacretaz wrote:
> On Thu, Nov 23, 2017 at 10:30 AM, Robert Munteanu  > wrote:
> > - rename sling to sling-archive...
> 
> How about sling-old-svn-mirror instead? That's more specific, we have
> several "archives".

That's a better name, will use that.

Thanks,

Robert

[jira] [Commented] (SLING-7262) Generate reusable list of repositories for machine consumption

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7262:


[~bdelacretaz] Thanks a lot. Looks much cleaner now!

> Generate reusable list of repositories for machine consumption
> --
>
> Key: SLING-7262
> URL: https://issues.apache.org/jira/browse/SLING-7262
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Robert Munteanu
>
> We currently have two 'clients' that query the github repos and the 
> .sling-module.xml descriptors:
> * the jenkins job creation DSL script
> * the repo manifest creation script
> We've also discussed in SLING-7161 the possibility of listing all 
> repositories on the website.
> To minimize the effort of talking to github in each location and reduce the 
> number of calls to Github ( for rate limiting purposes ) we should generate a 
> JSON/XML file that contains all information about the git repos. This file is 
> in turns read by various "clients" that need the information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [git] Retiring the old github.com/sling project

[Bertrand Delacretaz]

On Thu, Nov 23, 2017 at 10:30 AM, Robert Munteanu  wrote:
> - rename sling to sling-archive...

How about sling-old-svn-mirror instead? That's more specific, we have
several "archives".

-Bertrand

[jira] [Commented] (SLING-7262) Generate reusable list of repositories for machine consumption

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-7262:


I saw that Konrad's prototype duplicates some code from page.tpl, to avoid that 
I have refactored the templates utility code in 
https://github.com/apache/sling-site/commit/e21451fabcb1e7d36164b54f0393181b7f08d3f2

> Generate reusable list of repositories for machine consumption
> --
>
> Key: SLING-7262
> URL: https://issues.apache.org/jira/browse/SLING-7262
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Robert Munteanu
>
> We currently have two 'clients' that query the github repos and the 
> .sling-module.xml descriptors:
> * the jenkins job creation DSL script
> * the repo manifest creation script
> We've also discussed in SLING-7161 the possibility of listing all 
> repositories on the website.
> To minimize the effort of talking to github in each location and reduce the 
> number of calls to Github ( for rate limiting purposes ) we should generate a 
> JSON/XML file that contains all information about the git repos. This file is 
> in turns read by various "clients" that need the information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7157) metatype.properties file must not be in OSGI-INF/metatype

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-7157:


[~cziegeler] I wish to release JCR Registration 1.0.4 and see this issue 
referred for that. What changes do I need to make? I see metatype.properties 
but not metatype.xml so not sure where to refer the new location.

Also this module uses old annotations but I am again not sure on how to switch 
to new version of annotation as there is no replacement for References, non 
anotation type config. So not sure if its worth effort.

Can you have a look at the module and suggest how to move forward for release 
https://github.com/apache/sling-org-apache-sling-jcr-registration

> metatype.properties file must not be in OSGI-INF/metatype
> -
>
> Key: SLING-7157
> URL: https://issues.apache.org/jira/browse/SLING-7157
> Project: Sling
>  Issue Type: Bug
>Affects Versions: JCR Web Console 1.0.2, JCR Registration 1.0.2, JCR 
> ClassLoader 3.2.2, Form Based Authentication 1.0.8, Settings 1.3.8, Commons 
> Threads 3.2.6, Auth Core 1.4.0, SLF4J MDC Filter 1.0.0, Authentication XING 
> OAuth 0.0.2, Authentication XING Login 0.0.2, URL Rewriter 0.0.2, DataSource 
> Provider 1.0.4, NoSQL MongoDB Resource Provider 1.1.0, Commons Log 5.0.2, 
> Discovery Impl 1.2.12, Discovery Oak 1.2.18, JCR Davex 1.3.8, JCR Webdav 
> 2.3.8, JCR Installer 3.1.26
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: JCR Web Console 1.0.4, JCR Registration 1.0.4, JCR 
> ClassLoader 3.2.4, Form Based Authentication 1.0.10, Settings 1.3.10, Auth 
> Core 1.4.2, Mongo Resource Provider 1.0.0, Authentication XING OAuth 0.0.4, 
> Authentication XING Login 0.0.4, DataSource Provider 1.0.4, URL Rewriter 
> 0.0.4, Commons Log 5.0.4, Commons Threads 3.2.10, SLF4J MDC Filter 1.0.2, JCR 
> Webdav 2.3.10, JCR Installer 3.1.28, Discovery Impl 1.2.14, Discovery Oak 
> 1.2.24, JCR Davex 1.3.12
>
>
> According to the spec the metatype.properties file must not be inside the 
> OSGI-INF/metatype directory. This is against the spec, so we should move it 
> to OSGI-INF/l10n
> We probably should also upgrade the maven-scr-plugin for this 1.25.0
> I found the following files:
> ./bundles/auth/core/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/auth/form/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/commons/log/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/commons/threads/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/extensions/discovery/impl/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/extensions/discovery/oak/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/extensions/settings/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/classloader/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/davex/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/registration/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/webconsole/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./bundles/jcr/webdav/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/auth/org.apache.sling.auth.xing.login/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/auth/org.apache.sling.auth.xing.oauth/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/datasource/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/mongodb/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/slf4j-mdc/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/startup-filter/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./contrib/extensions/urlrewriter/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./installer/providers/jcr/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./samples/path-based-rtp/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./samples/workspacepicker/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./testing/junit/core/src/main/resources/OSGI-INF/metatype/metatype.properties
> ./testing/junit/healthcheck/src/main/resources/OSGI-INF/metatype/metatype.properties



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7263) Make RMI package optional

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-7263.

Resolution: Fixed

Marked optional with 
[commit|https://gitbox.apache.org/repos/asf?p=sling-org-apache-sling-jcr-registration.git;a=commitdiff;h=1952fb14d5337a011c922afe84c15e20a90294e2]

> Make RMI package optional 
> --
>
> Key: SLING-7263
> URL: https://issues.apache.org/jira/browse/SLING-7263
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Registration 1.0.4
>
>
> org.apache.sling.jcr.registration bundle currently imports following packages
> {noformat}
>   javax.jcr {version=[2.0,3)}
>   javax.naming  
>   javax.naming.spi  
>   javax.transaction.xa  {resolution:=optional}
>   org.apache.jackrabbit.rmi.remote  {version=[2.0,3)}
>   org.apache.jackrabbit.rmi.server  {version=[2.0,3)}
>   org.apache.sling.jcr.registration {version=[1.1,1.2)}
>   org.osgi.framework{version=[1.4,2)}
>   org.osgi.service.component{version=[1.0,2)}
>   org.osgi.service.log  {version=[1.3,2)}
> {noformat}
> Due to required import for "org.apache.jackrabbit.rmi" package this bundle 
> cannot be used on setups where "org.apache.jackrabbit.jackrabbit-jcr-rmi" is 
> not present. To enable usage (JNDI registration part) on such setups we 
> should mark these packages as optional



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7263) Make RMI package optional

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-7263:
---
Priority: Minor  (was: Major)

> Make RMI package optional 
> --
>
> Key: SLING-7263
> URL: https://issues.apache.org/jira/browse/SLING-7263
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: JCR Registration 1.0.4
>
>
> org.apache.sling.jcr.registration bundle currently imports following packages
> {noformat}
>   javax.jcr {version=[2.0,3)}
>   javax.naming  
>   javax.naming.spi  
>   javax.transaction.xa  {resolution:=optional}
>   org.apache.jackrabbit.rmi.remote  {version=[2.0,3)}
>   org.apache.jackrabbit.rmi.server  {version=[2.0,3)}
>   org.apache.sling.jcr.registration {version=[1.1,1.2)}
>   org.osgi.framework{version=[1.4,2)}
>   org.osgi.service.component{version=[1.0,2)}
>   org.osgi.service.log  {version=[1.3,2)}
> {noformat}
> Due to required import for "org.apache.jackrabbit.rmi" package this bundle 
> cannot be used on setups where "org.apache.jackrabbit.jackrabbit-jcr-rmi" is 
> not present. To enable usage (JNDI registration part) on such setups we 
> should mark these packages as optional



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7263) Make RMI package optional

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-7263:
--

 Summary: Make RMI package optional 
 Key: SLING-7263
 URL: https://issues.apache.org/jira/browse/SLING-7263
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
 Fix For: JCR Registration 1.0.4


org.apache.sling.jcr.registration bundle currently imports following packages

{noformat}
  javax.jcr {version=[2.0,3)}
  javax.naming  
  javax.naming.spi  
  javax.transaction.xa  {resolution:=optional}
  org.apache.jackrabbit.rmi.remote  {version=[2.0,3)}
  org.apache.jackrabbit.rmi.server  {version=[2.0,3)}
  org.apache.sling.jcr.registration {version=[1.1,1.2)}
  org.osgi.framework{version=[1.4,2)}
  org.osgi.service.component{version=[1.0,2)}
  org.osgi.service.log  {version=[1.3,2)}
{noformat}

Due to required import for "org.apache.jackrabbit.rmi" package this bundle 
cannot be used on setups where "org.apache.jackrabbit.jackrabbit-jcr-rmi" is 
not present. To enable usage (JNDI registration part) on such setups we should 
mark these packages as optional



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

RE: [git] Retiring the old github.com/sling project

[Stefan Seifert]

+1

>-Original Message-
>From: Robert Munteanu [mailto:romb...@apache.org]
>Sent: Thursday, November 23, 2017 10:30 AM
>To: dev@sling.apache.org
>Subject: [git] Retiring the old github.com/sling project
>
>Hi,
>
>We discussed the 'old' github.com/sling mirror on and off, but never
>reached a conclusion.
>
>Based on previous emails, I proposed that we:
>
>- rename sling to sling-archive. Github will generate redirects so
>links are not lost, but the role of the repostiory is now clear
>- change the default branch to 'archived' ( see [1] ) so first-time
>visitors will not clone it or use it for meaningful work.
>
>Thoughts?
>
>Thanks,
>
>Robert
>
>[1]: https://github.com/apache/sling/tree/archived

Re: [git] Retiring the old github.com/sling project

[Radu Cotescu]

+1

On Thu, 23 Nov 2017 at 11:14 Karl Pauls  wrote:

> +1 - sounds good to me
>
> regards,
>
> Karl
>
> On Thu, Nov 23, 2017 at 11:00 AM, Antonio Sanso
>  wrote:
> > +1
> > On Nov 23, 2017, at 10:30 AM, Robert Munteanu 
> wrote:
> >
> >> Hi,
> >>
> >> We discussed the 'old' github.com/sling mirror on and off, but never
> >> reached a conclusion.
> >>
> >> Based on previous emails, I proposed that we:
> >>
> >> - rename sling to sling-archive. Github will generate redirects so
> >> links are not lost, but the role of the repostiory is now clear
> >> - change the default branch to 'archived' ( see [1] ) so first-time
> >> visitors will not clone it or use it for meaningful work.
> >>
> >> Thoughts?
> >>
> >> Thanks,
> >>
> >> Robert
> >>
> >> [1]: https://github.com/apache/sling/tree/archived
> >
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

Re: [git] Retiring the old github.com/sling project

[Karl Pauls]

+1 - sounds good to me

regards,

Karl

On Thu, Nov 23, 2017 at 11:00 AM, Antonio Sanso
 wrote:
> +1
> On Nov 23, 2017, at 10:30 AM, Robert Munteanu  wrote:
>
>> Hi,
>>
>> We discussed the 'old' github.com/sling mirror on and off, but never
>> reached a conclusion.
>>
>> Based on previous emails, I proposed that we:
>>
>> - rename sling to sling-archive. Github will generate redirects so
>> links are not lost, but the role of the repostiory is now clear
>> - change the default branch to 'archived' ( see [1] ) so first-time
>> visitors will not clone it or use it for meaningful work.
>>
>> Thoughts?
>>
>> Thanks,
>>
>> Robert
>>
>> [1]: https://github.com/apache/sling/tree/archived
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [git] Retiring the old github.com/sling project

[Antonio Sanso]

+1
On Nov 23, 2017, at 10:30 AM, Robert Munteanu  wrote:

> Hi,
> 
> We discussed the 'old' github.com/sling mirror on and off, but never
> reached a conclusion.
> 
> Based on previous emails, I proposed that we:
> 
> - rename sling to sling-archive. Github will generate redirects so
> links are not lost, but the role of the repostiory is now clear
> - change the default branch to 'archived' ( see [1] ) so first-time
> visitors will not clone it or use it for meaningful work.
> 
> Thoughts?
> 
> Thanks,
> 
> Robert
> 
> [1]: https://github.com/apache/sling/tree/archived

Re: [git] Retiring the old github.com/sling project

[Konrad Windszus]

+1

> On 23. Nov 2017, at 10:30, Robert Munteanu  wrote:
> 
> Hi,
> 
> We discussed the 'old' github.com/sling mirror on and off, but never
> reached a conclusion.
> 
> Based on previous emails, I proposed that we:
> 
> - rename sling to sling-archive. Github will generate redirects so
> links are not lost, but the role of the repostiory is now clear
> - change the default branch to 'archived' ( see [1] ) so first-time
> visitors will not clone it or use it for meaningful work.
> 
> Thoughts?
> 
> Thanks,
> 
> Robert
> 
> [1]: https://github.com/apache/sling/tree/archived

[git] Retiring the old github.com/sling project

[Robert Munteanu]

Hi,

We discussed the 'old' github.com/sling mirror on and off, but never
reached a conclusion.

Based on previous emails, I proposed that we:

- rename sling to sling-archive. Github will generate redirects so
links are not lost, but the role of the repostiory is now clear
- change the default branch to 'archived' ( see [1] ) so first-time
visitors will not clone it or use it for meaningful work.

Thoughts?

Thanks,

Robert

[1]: https://github.com/apache/sling/tree/archived

[jira] [Assigned] (SLING-7183) Update old 'sling' github mirror to reflect Git migration

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-7183:
--

Assignee: Robert Munteanu

> Update old 'sling' github mirror to reflect Git migration
> -
>
> Key: SLING-7183
> URL: https://issues.apache.org/jira/browse/SLING-7183
> Project: Sling
>  Issue Type: Sub-task
>  Components: Best practices
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> We had some long discussions on the dev@list ( see for instance [What to do 
> with 
> github.com/apache/sling|https://lists.apache.org/thread.html/3cd73a6b55423e07424fae54fead688e854f190ee8309257e13a1381@%3Cdev.sling.apache.org%3E]
>  and came to the conclusion that we can't delete the old sling github mirror. 
> If we do that, all links to commits and pull requests would be broken. A 
> couple of ideas were circulated:
> - change the default branch to archived and add only a README file ( the 
> branch exists, but default was not changed - 
> https://github.com/apache/sling/tree/archived )
> - delete the contents of the trunk branch and leave just a README ; also tag 
> the last state of trunk to keep the commits around ( this breaks links that 
> include 'trunk' though )
> - rename the repo to sling-something-else ; git will generate redirects
> For whatever we decided to do we need to decide first and then ask infra for 
> assistance - we can't change the git repo setup ourselves.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7161) Update site to reference git instead of svn

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7161:


[~kwin] - I think that's a good idea. I created SLING-7262 to track the 
creation of the JSON/XML file.

> Update site to reference git instead of svn
> ---
>
> Key: SLING-7161
> URL: https://issues.apache.org/jira/browse/SLING-7161
> Project: Sling
>  Issue Type: Sub-task
>  Components: Site
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> All the https://svn.apache.org/repos/asf/sling/... tags should be rewritten 
> to the git repos.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7262) Generate reusable list of repositories for machine consumption

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-7262:
--

 Summary: Generate reusable list of repositories for machine 
consumption
 Key: SLING-7262
 URL: https://issues.apache.org/jira/browse/SLING-7262
 Project: Sling
  Issue Type: Task
  Components: Build and Source Control
Reporter: Robert Munteanu


We currently have two 'clients' that query the github repos and the 
.sling-module.xml descriptors:

* the jenkins job creation DSL script
* the repo manifest creation script

We've also discussed in SLING-7161 the possibility of listing all repositories 
on the website.

To minimize the effort of talking to github in each location and reduce the 
number of calls to Github ( for rate limiting purposes ) we should generate a 
JSON/XML file that contains all information about the git repos. This file is 
in turns read by various "clients" that need the information.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (SLING-7161) Update site to reference git instead of svn

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7161:


IMHO we should still provide a table with URLs to all Sling repositories (both 
Github and Gitbox). My branch at 
https://github.com/apache/sling-site/tree/scm-project-url-list provides such a 
thing.
What about the plan of having a single job retrieving all repos and writing the 
information to JSON/XML?
[~rombert] Can you quickly comment on that?

> Update site to reference git instead of svn
> ---
>
> Key: SLING-7161
> URL: https://issues.apache.org/jira/browse/SLING-7161
> Project: Sling
>  Issue Type: Sub-task
>  Components: Site
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> All the https://svn.apache.org/repos/asf/sling/... tags should be rewritten 
> to the git repos.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Sling Starter Startup 1.0.4

[Robert Munteanu]

On Wed, 2017-11-22 at 16:25 +, Radu Cotescu wrote:
> Please vote to approve this release:

+1

Robert

signature.asc
Description: This is a digitally signed message part

Release check scripts moved to sling-tooling-release repo

[Robert Munteanu]

Hi,

The check_staged_release.sh, check_release_matches_tag.sh and KEYS
files have been relocated to the sling-tooling-release repo.

I've updated the release management page [1] to reference the GitBox
URL for them, instead of SVN.

Now would be a good time to remove the old SVN/git-svn clone and use
only the git repos ;-)

Thanks,

Robert

[1]: https://sling.apache.org/documentation/development/release-managem
ent.html