Re: utility to add logger to paxexam

[Nicolas Peltier]

that did help! (updated the ticket)
thanks a lot!

2017-10-05 19:36 GMT+02:00 Oliver Lietz :
> On Thursday 05 October 2017 18:48:35 Nicolas Peltier wrote:
>> Hey,
>
> Hi Nicolas,
>
>> am aching to add a logger in DEBUG/TRACE on my bundle for paxexam,
>> would you feel like an utility for that would be useful?
>
> have a look at SLING-6665 and Logging Configuration and let me know if that
> helps:
>
> https://issues.apache.org/jira/browse/SLING-6665
>
> https://github.com/apache/sling/tree/trunk/contrib/scripting/org.apache.sling.scripting.thymeleaf/src/test/resources
>
> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263891/Logging+Configuration
>
> Regards,
> O.
>
>> nice to have would be muting some others too
>>
>> Nicolas
>

[jira] [Commented] (SLING-6665) Provide a logging Option for Pax Exam

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier commented on SLING-6665:


[~olli] just added my vote as this would be a big enhancement!

> Provide a logging Option for Pax Exam
> -
>
> Key: SLING-6665
> URL: https://issues.apache.org/jira/browse/SLING-6665
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.4
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>
> From {{ThymeleafTestSupport}}:
> {noformat}
> protected Option logging() {
> final String filename = 
> String.format("file:%s/src/test/resources/logback.xml", 
> PathUtils.getBaseDir());
> return composite(
> systemProperty("logback.configurationFile").value(filename),
> 
> mavenBundle().groupId("org.slf4j").artifactId("slf4j-api").version("1.7.21"),
> 
> mavenBundle().groupId("org.slf4j").artifactId("jcl-over-slf4j").version("1.7.21"),
> 
> mavenBundle().groupId("ch.qos.logback").artifactId("logback-core").version("1.1.7"),
> 
> mavenBundle().groupId("ch.qos.logback").artifactId("logback-classic").version("1.1.7")
> );
> }
> {noformat}



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

Re: utility to add logger to paxexam

[Oliver Lietz]

On Thursday 05 October 2017 18:48:35 Nicolas Peltier wrote:
> Hey,

Hi Nicolas,

> am aching to add a logger in DEBUG/TRACE on my bundle for paxexam,
> would you feel like an utility for that would be useful?

have a look at SLING-6665 and Logging Configuration and let me know if that 
helps:

https://issues.apache.org/jira/browse/SLING-6665

https://github.com/apache/sling/tree/trunk/contrib/scripting/org.apache.sling.scripting.thymeleaf/src/test/resources

https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/pages/54263891/Logging+Configuration

Regards,
O.

> nice to have would be muting some others too
> 
> Nicolas

[jira] [Commented] (SLING-6868) Initial content should be migrated to bundle resources

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac commented on SLING-6868:
--

[~cziegeler], i went ahead and removed the query altogether as there's a types 
cache. And now it just looks at the direct descendants of the search paths. 
Long story short, everything seems to work, yay :) Thanks for the help!

> Initial content should be migrated to bundle resources
> --
>
> Key: SLING-6868
> URL: https://issues.apache.org/jira/browse/SLING-6868
> Project: Sling
>  Issue Type: Bug
>  Components: HApi
>Affects Versions: HApi 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Andrei Dulvac
> Fix For: HApi 1.1.0
>
>
> Currently the initial content in the hapi bundle does not specify a path, 
> which means it is using "/".
> When applied at the wrong time, it potentially could wipe the whole 
> repository. In addition initial content should always be specified with the 
> most specific path (the tree the bundle is owning)
> So the path is something like /libs/sling/hapi
> or even
> /libs/sling/hapi/components



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

utility to add logger to paxexam

[Nicolas Peltier]

Hey,

am aching to add a logger in DEBUG/TRACE on my bundle for paxexam,
would you feel like an utility for that would be useful?

nice to have would be muting some others too

Nicolas

[jira] [Commented] (SLING-6868) Initial content should be migrated to bundle resources

[Andrei Dulvac (JIRA)]

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

Andrei Dulvac commented on SLING-6868:
--

[~cziegeler], That's because I'm making a jcr query to get the resource from 
the fqdn property in a subtree of the repo:
https://github.com/apache/sling/blob/trunk/contrib/extensions/hapi/core/src/main/java/org/apache/sling/hapi/impl/HApiUtilImpl.java#L173-L190
 
This obviously doesn't work. I don't really know how to proceed...

I had a look at https://sling.apache.org/documentation/bundles/sling-query.html 
but that's not much of a query, just trivial traversal - no indices, etc.
Any ideas?


> Initial content should be migrated to bundle resources
> --
>
> Key: SLING-6868
> URL: https://issues.apache.org/jira/browse/SLING-6868
> Project: Sling
>  Issue Type: Bug
>  Components: HApi
>Affects Versions: HApi 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Andrei Dulvac
> Fix For: HApi 1.1.0
>
>
> Currently the initial content in the hapi bundle does not specify a path, 
> which means it is using "/".
> When applied at the wrong time, it potentially could wipe the whole 
> repository. In addition initial content should always be specified with the 
> most specific path (the tree the bundle is owning)
> So the path is something like /libs/sling/hapi
> or even
> /libs/sling/hapi/components



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

[jira] [Commented] (SLING-7169) FullTextIndexingTest sometimes fails with a timeout

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7169:


Asked on the Oak list for a way to wait for indexing to complete - 
https://lists.apache.org/thread.html/a49a31f823a6dc014f3a2ff7956fca89efa6db76bacea14c637ea48a@%3Coak-dev.jackrabbit.apache.org%3E

> FullTextIndexingTest sometimes fails with a timeout
> ---
>
> Key: SLING-7169
> URL: https://issues.apache.org/jira/browse/SLING-7169
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>Reporter: Robert Munteanu
>  Labels: sling-IT
> Attachments: SLING-7169-logs.tar.gz
>
>
> The test fails maybe 1 in 10 runs. I could reproduce this locally by running 
> many times. I've also seen it once on Jenkins.
> **Old description below**
> After upgrading the launchpad to commons.threads 3.2.10 the 
> FullTextIndexingTest failed ( [build 
> 1547|https://builds.apache.org/job/sling-launchpad-testing-1.8/1547/] ).
> I also reproduced it once locally.
> [~kwin] - since the commons.threads release is the potential root cause, can 
> you please take a look at the failure and see if it's related?



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

Re: [RT] Updates to the provisioning model

[Julian Sedding]

Hi Bertrand

I suppose it would be

cat provisioning-model | jsmin | jq .

I have not tested this, however.

Regards
Julian


On Thu, Oct 5, 2017 at 3:39 PM, Bertrand Delacretaz
 wrote:
> On Thu, Oct 5, 2017 at 11:39 AM, Julian Sedding  wrote:
>> ...lets stick with JSON + comments...
>
> Is that format accepted by JSON tools? Can I for example do
>
>   cat provisioning-model | jq .
>
> ?
>
> Otherwise I fear the format combines the worst of both worlds: hard
> for humans to read and write (JSON) and not directly suitable for
> machine processing. In which case I suggest rediscussing the comments
> format/schema to make sure the result is pure JSON - maybe with
> _comment_ elements that tools can easily ignore.
>
> -Bertrand

Re: [RT] Updates to the provisioning model

[Carsten Ziegeler]

I don't think jq supports comments.

But as I stated, all our code writes out perfectly valid JSON without
any comments. So you can use this with any tooling that supports JSON.

*If* you want to have comments in your source feature, we currently
support them as described.

Now, looking at the existing provisioning models, I think that is
enough. However if people feel strong about it, we could add special
comment properties here and there. But then the whole processing gets
way more complicated and bloated as we have to drag them around, think
about how to handle them when merging etc. In addition, the OSGi
configuration specification does not allow such properties, so
configurations would be out of the picture.

It really seems to be a rare use case for which I don't want to clutter
the spec with

Carsten


Bertrand Delacretaz wrote
> On Thu, Oct 5, 2017 at 11:39 AM, Julian Sedding  wrote:
>> ...lets stick with JSON + comments...
> 
> Is that format accepted by JSON tools? Can I for example do
> 
>   cat provisioning-model | jq .
> 
> ?
> 
> Otherwise I fear the format combines the worst of both worlds: hard
> for humans to read and write (JSON) and not directly suitable for
> machine processing. In which case I suggest rediscussing the comments
> format/schema to make sure the result is pure JSON - maybe with
> _comment_ elements that tools can easily ignore.
> 
> -Bertrand
> 
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [RT] Updates to the provisioning model

[Bertrand Delacretaz]

On Thu, Oct 5, 2017 at 11:39 AM, Julian Sedding  wrote:
> ...lets stick with JSON + comments...

Is that format accepted by JSON tools? Can I for example do

  cat provisioning-model | jq .

?

Otherwise I fear the format combines the worst of both worlds: hard
for humans to read and write (JSON) and not directly suitable for
machine processing. In which case I suggest rediscussing the comments
format/schema to make sure the result is pure JSON - maybe with
_comment_ elements that tools can easily ignore.

-Bertrand

Re: [Site] Improving the main site

[Oliver Lietz]

On Wednesday 04 October 2017 16:18:56 Carsten Ziegeler wrote:
> I think "headless" puts us into a specific bucket. You can build
> anything with Sling, being it headless or not. AEM is definitely not
> headless :) I think it doesn't make sense for a framework to use that
> characterisation, otherwise a lot of frameworks are headless (in the
> sense of not having a UI)

+1

O.

> Carsten
> 
> 
> Bertrand Delacretaz wrote
> 
> > Hi Karl,
> > 
> > On Wed, Oct 4, 2017 at 3:44 PM, Karl Pauls  wrote:
> >> ...3. It is more than 100 words :-)..
> > 
> > I don't think that's important, "short" is good enough IMO.
> > 
> > Ruben suggests "headless" which I like (and it's a good excuse for
> > many of our examples UIs ;-)
> > 
> > So two suggestions from my side, inline:
> >> Apache Sling is a framework for RESTful web-applications based on an
> >> extensible content tree.
> > 
> > "headless framework"
> > 
> >> In a nutshell, Sling maps URL requests to resources based on the
> >> request's path, extension and selectors. Using convention over
> >> configuration, request processing itself is based on scripts and
> >> servlets selected based on a given resource. Together, this enables
> >> meaningful URLs and resource driven request processing while the
> >> modular nature of Sling allows for specialized server instances that
> >> include only what is needed.
> >> 
> >> Sling serves as basis for a variety of applications - ranging from
> >> blogging engines all the way to industrial strength content management
> >> systems.
> > 
> > ...where its robustness and simplicity shine
> > 
> > -Bertrand

Re: [Site] Improving the main site

[Oliver Lietz]

On Wednesday 04 October 2017 15:44:12 Karl Pauls wrote:
[...]
> Apache Sling is a framework for RESTful web-applications based on an
> extensible content tree.
> 
> In a nutshell, Sling maps URL requests to resources based on the
> request's path, extension and selectors. Using convention over
> configuration, request processing itself is based on scripts and
> servlets selected based on a given resource. Together, this enables
> meaningful URLs and resource driven request processing while the
> modular nature of Sling allows for specialized server instances that
> include only what is needed.
> 
> Sling serves as basis for a variety of applications - ranging from
> blogging engines all the way to industrial strength content management
> systems.

+1 (s/industrial strength/enterprise/)

O.

> regards,
> 
> Karl

Re: [RT] Updates to the provisioning model

[Julian Sedding]

Hi Carsten

That's fine with me. It just seemed like it might be a good fit
because of the comments. Seen that you went down that route already,
lets stick with JSON + comments.

Regards
Julian


On Thu, Oct 5, 2017 at 11:23 AM, Carsten Ziegeler  wrote:
> Hi Julian
>
> yes, we considered YAML. First of all, the OSGi Configuration Admin
> specification will use JSON. That spec started with using YAML, but in
> the end no one was happy with the format, so we replaced YAML with JSON.
>
> While YAML can support JSON, no one really does this - so we end up with
> real YAML and JSON mixed. Which is confusing. And YAML is not practical
> as soon as your document gets to a certain size.
>
> Or in other words :) I'm very much opposed to using YAML. Let's keep it
> simple and JSON works fine.
>
> The JSON comments are based on what everyone seems to use ([1]). It's
> easy to explain and easy to process.
>
> Regards
>
> Carsten
>
> [1] https://github.com/douglascrockford/JSMin
>
>
> Julian Sedding wrote
>> Hi Carsten
>>
>> This looks very interesting!
>>
>> Regarding the format, have you considered YAML? It is a superset of
>> JSON (well, it's designed to also support JSON syntax) and it allows
>> comments out of the box. Furthermore, it's well specified (in contrast
>> to JSON with comments). I assume that using YAML, people could choose
>> whether they want to write it more JSOn style or YAML style.
>>
>> Regards
>> Julian
>>
>>
>> On Wed, Oct 4, 2017 at 10:12 AM, Robert Munteanu  wrote:
>>> On Wed, 2017-10-04 at 10:01 +0200, Carsten Ziegeler wrote:
 Robert Munteanu wrote> On Tue, 2017-10-03 at 11:52 +0200, Carsten
 Ziegeler wrote:

>>> 2. Reading the section on configuration merging, it is not
>>> clear to
>>> me
>>> if merging is merging of values or overriding of values.
>>>
>>> Consider
>>>
>>>
>>> feature 1:
>>>
>>> com.foo.bar.Service
>>>prop1="A"
>>>prop2="B"
>>>
>>> feature 2:
>>>
>>> com.foo.bar.Service
>>>prop1="C"
>>>
>>>
>>> After the merge, will the configuration define the prop2
>>> property?
>>
>> Yes, values get overwritten.
>
> Is there any way of removing a configuration property once it's
> defined
> in a feature?
>

 Yes, if a feature is includes other features, the include instruction
 can have any number of removals.
 So you can remove properties before, bundles etc.
>>>
>>>
>>> So I guess we have most (or even all) annoyances from the provisioning
>>> model covered, which is great.
>>>
>>> Thanks,
>>>
>>> Robert
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

[jira] [Commented] (SLING-6868) Initial content should be migrated to bundle resources

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6868:
-

[~andrei.dulvac] Right, that should work.
I've commited two fixes now and the script is now correctly picked up I think. 
However now I get:
org.apache.sling.hapi.HApiException: Property hapi_name does not exist for type 
null

Any idea on what could be going wrong?

> Initial content should be migrated to bundle resources
> --
>
> Key: SLING-6868
> URL: https://issues.apache.org/jira/browse/SLING-6868
> Project: Sling
>  Issue Type: Bug
>  Components: HApi
>Affects Versions: HApi 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Andrei Dulvac
> Fix For: HApi 1.1.0
>
>
> Currently the initial content in the hapi bundle does not specify a path, 
> which means it is using "/".
> When applied at the wrong time, it potentially could wipe the whole 
> repository. In addition initial content should always be specified with the 
> most specific path (the tree the bundle is owning)
> So the path is something like /libs/sling/hapi
> or even
> /libs/sling/hapi/components



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

Re: [RT] Updates to the provisioning model

[Carsten Ziegeler]

Hi Julian

yes, we considered YAML. First of all, the OSGi Configuration Admin
specification will use JSON. That spec started with using YAML, but in
the end no one was happy with the format, so we replaced YAML with JSON.

While YAML can support JSON, no one really does this - so we end up with
real YAML and JSON mixed. Which is confusing. And YAML is not practical
as soon as your document gets to a certain size.

Or in other words :) I'm very much opposed to using YAML. Let's keep it
simple and JSON works fine.

The JSON comments are based on what everyone seems to use ([1]). It's
easy to explain and easy to process.

Regards

Carsten

[1] https://github.com/douglascrockford/JSMin


Julian Sedding wrote
> Hi Carsten
> 
> This looks very interesting!
> 
> Regarding the format, have you considered YAML? It is a superset of
> JSON (well, it's designed to also support JSON syntax) and it allows
> comments out of the box. Furthermore, it's well specified (in contrast
> to JSON with comments). I assume that using YAML, people could choose
> whether they want to write it more JSOn style or YAML style.
> 
> Regards
> Julian
> 
> 
> On Wed, Oct 4, 2017 at 10:12 AM, Robert Munteanu  wrote:
>> On Wed, 2017-10-04 at 10:01 +0200, Carsten Ziegeler wrote:
>>> Robert Munteanu wrote> On Tue, 2017-10-03 at 11:52 +0200, Carsten
>>> Ziegeler wrote:
>>>
>> 2. Reading the section on configuration merging, it is not
>> clear to
>> me
>> if merging is merging of values or overriding of values.
>>
>> Consider
>>
>>
>> feature 1:
>>
>> com.foo.bar.Service
>>prop1="A"
>>prop2="B"
>>
>> feature 2:
>>
>> com.foo.bar.Service
>>prop1="C"
>>
>>
>> After the merge, will the configuration define the prop2
>> property?
>
> Yes, values get overwritten.

 Is there any way of removing a configuration property once it's
 defined
 in a feature?

>>>
>>> Yes, if a feature is includes other features, the include instruction
>>> can have any number of removals.
>>> So you can remove properties before, bundles etc.
>>
>>
>> So I guess we have most (or even all) annoyances from the provisioning
>> model covered, which is great.
>>
>> Thanks,
>>
>> Robert
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Created] (SLING-7180) Set up a Jenkins job for automatically publishing the Sling site

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-7180:
--

 Summary: Set up a Jenkins job for automatically publishing the 
Sling site
 Key: SLING-7180
 URL: https://issues.apache.org/jira/browse/SLING-7180
 Project: Sling
  Issue Type: Improvement
  Components: Site
Reporter: Robert Munteanu
Priority: Minor


Once we move to gitbox we should also automatically build + push the site from 
a Jenkins job so that all we need to do is {{git push}} from the master branch.



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

Re: [site] Simplifying publishing process

[Robert Munteanu]

On Thu, 2017-10-05 at 10:58 +0300, Robert Munteanu wrote:
> On Wed, 2017-10-04 at 18:28 +0200, Konrad Windszus wrote:
> > Sorry, I missed the point that web sites can only be published if
> > the
> > source files are in Git [1].
> > If I understand correctly the only thing that the maven-scm-
> > publish-
> > plugin would do is committing the target site to the asf-branch
> > (what
> > we currently need to do manually).
> 
> Yes, that's what I'm working on.

And it's done. Readme updated, and here for completeness:

  mvn clean package -Prun-site

to run the site, and

  mvn clean package -Ppublish-site

to publish the site.

Of course, the manual approach works as well, but we don't really have
to do that anymore. I'll set up a Jenkins job _after_ we get the gitbox
stuff set up.

Robert

[jira] [Commented] (SLING-7178) Allow publishing the Sling site using Maven

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-7178:


Fixed in multiple steps, README updates as well.

> Allow publishing the Sling site using Maven
> ---
>
> Key: SLING-7178
> URL: https://issues.apache.org/jira/browse/SLING-7178
> Project: Sling
>  Issue Type: Improvement
>  Components: Site
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> The new sling site publish process is a bit manual. We should be able to 
> automate this to reduce reliance on typing shell commands. See also the 
> discussion at 
> https://lists.apache.org/thread.html/16bee57e484fb829d0d530e0527632438286c0ed28fd6e4d67bd050e@%3Cdev.sling.apache.org%3E



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

[jira] [Resolved] (SLING-7178) Allow publishing the Sling site using Maven

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-7178.

Resolution: Fixed

> Allow publishing the Sling site using Maven
> ---
>
> Key: SLING-7178
> URL: https://issues.apache.org/jira/browse/SLING-7178
> Project: Sling
>  Issue Type: Improvement
>  Components: Site
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> The new sling site publish process is a bit manual. We should be able to 
> automate this to reduce reliance on typing shell commands. See also the 
> discussion at 
> https://lists.apache.org/thread.html/16bee57e484fb829d0d530e0527632438286c0ed28fd6e4d67bd050e@%3Cdev.sling.apache.org%3E



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

[jira] [Assigned] (SLING-7178) Allow publishing the Sling site using Maven

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-7178:
--

Assignee: Robert Munteanu

> Allow publishing the Sling site using Maven
> ---
>
> Key: SLING-7178
> URL: https://issues.apache.org/jira/browse/SLING-7178
> Project: Sling
>  Issue Type: Improvement
>  Components: Site
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> The new sling site publish process is a bit manual. We should be able to 
> automate this to reduce reliance on typing shell commands. See also the 
> discussion at 
> https://lists.apache.org/thread.html/16bee57e484fb829d0d530e0527632438286c0ed28fd6e4d67bd050e@%3Cdev.sling.apache.org%3E



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

Re: [RT] Updates to the provisioning model

[Julian Sedding]

Hi Carsten

This looks very interesting!

Regarding the format, have you considered YAML? It is a superset of
JSON (well, it's designed to also support JSON syntax) and it allows
comments out of the box. Furthermore, it's well specified (in contrast
to JSON with comments). I assume that using YAML, people could choose
whether they want to write it more JSOn style or YAML style.

Regards
Julian


On Wed, Oct 4, 2017 at 10:12 AM, Robert Munteanu  wrote:
> On Wed, 2017-10-04 at 10:01 +0200, Carsten Ziegeler wrote:
>> Robert Munteanu wrote> On Tue, 2017-10-03 at 11:52 +0200, Carsten
>> Ziegeler wrote:
>>
>> > > > 2. Reading the section on configuration merging, it is not
>> > > > clear to
>> > > > me
>> > > > if merging is merging of values or overriding of values.
>> > > >
>> > > > Consider
>> > > >
>> > > >
>> > > > feature 1:
>> > > >
>> > > > com.foo.bar.Service
>> > > >prop1="A"
>> > > >prop2="B"
>> > > >
>> > > > feature 2:
>> > > >
>> > > > com.foo.bar.Service
>> > > >prop1="C"
>> > > >
>> > > >
>> > > > After the merge, will the configuration define the prop2
>> > > > property?
>> > >
>> > > Yes, values get overwritten.
>> >
>> > Is there any way of removing a configuration property once it's
>> > defined
>> > in a feature?
>> >
>>
>> Yes, if a feature is includes other features, the include instruction
>> can have any number of removals.
>> So you can remove properties before, bundles etc.
>
>
> So I guess we have most (or even all) annoyances from the provisioning
> model covered, which is great.
>
> Thanks,
>
> Robert

[GitHub] sling-site pull request #2: Update manipulating-content-the-slingpostservlet...

[gauravs23]

GitHub user gauravs23 opened a pull request:

https://github.com/apache/sling-site/pull/2

Update manipulating-content-the-slingpostservlet-servlets-post.md

Update node name and node type generation algorithm description in case of 
File Uploads using SlingPostServlet

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gauravs23/sling-site master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling-site/pull/2.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2


commit a4cbdeb48685eefc2288d13d19da660ca9cc6b5a
Author: gauravs23 
Date:   2017-10-05T08:36:47Z

Update manipulating-content-the-slingpostservlet-servlets-post.md

Update node name and node type generation algorithm description in case of 
File Uploads using SlingPostServlet




---

[jira] [Commented] (SLING-7163) Update Jenkins jobs to reference the git repositories

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-7163:


At the same time we should disable polling and rather rely on the GitPubSub as 
well (see 
https://blogs.apache.org/infra/entry/bringing-gitpubsub-to-the-apache). Maybe 
we should even set those jobs up as multibranch jobs 
(https://www.cloudbees.com/blog/using-multi-branch-pipelines-apache-maven-project).

> Update Jenkins jobs to reference the git repositories
> -
>
> Key: SLING-7163
> URL: https://issues.apache.org/jira/browse/SLING-7163
> Project: Sling
>  Issue Type: Sub-task
>  Components: Best practices
>Reporter: Robert Munteanu
>
> As a first step, we should probably disable/delete all 'old' jobs. Then we 
> should re-create them pointing to the git repos.



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

Re: [site] Simplifying publishing process

[Robert Munteanu]

On Wed, 2017-10-04 at 18:28 +0200, Konrad Windszus wrote:
> Sorry, I missed the point that web sites can only be published if the
> source files are in Git [1].
> If I understand correctly the only thing that the maven-scm-publish-
> plugin would do is committing the target site to the asf-branch (what
> we currently need to do manually).

Yes, that's what I'm working on.

> So for me 1 & 2 are not mutually exclusive options, but 2 makes 1
> actually a lot easier, because then 1 is only a simple Maven goal.

Exactly.

Robert

> 
> Otherwise the Jenkins job would need to do those SCM operations
> manually.
> 
> [1] - https://blogs.apache.org/infra/entry/git_based_websites_availab
> le
> 
> > Am 04.10.2017 um 16:26 schrieb Robert Munteanu 
> > :
> > 
> > On Wed, 2017-10-04 at 12:16 +0200, Konrad Windszus wrote:
> > > > On 4. Oct 2017, at 12:11, Bertrand Delacretaz  > > > he.o
> > > > rg> wrote:
> > > > 
> > > > On Wed, Oct 4, 2017 at 12:07 PM, Konrad Windszus  > > > de>
> > > > wrote:
> > > > > ...I prefer 2 to not pollute the Sling Site Git repo with
> > > > > generated artifacts...
> > > > 
> > > > But it's *very* useful to be able to see the diffs of the
> > > > published
> > > > content before pushing them live.
> > > 
> > > Once we fixed all bugs in our templates, the diff on the MD
> > > source
> > > files is IMHO enough.
> > 
> > 
> > I am not sure how 1 would pollute the git repo ... The process
> > right
> > now is to build the HTML files and resync the asf-site branch with
> > the
> > output.
> > 
> > But anyway I think that having a Jenkins job that pushes every
> > change
> > on the master branch automatically using the maven-scm-publish
> > plugin
> > would be nice.
> > 
> > So I would first implement 2) and then 1). And of course we can
> > still
> > preview changes locally, for larger changes.
> > 
> > How does that sound?
> > 
> > Robert
> 
> 

[jira] [Resolved] (SLING-7175) Improve concurrency in FSDynamicClassLoader

[Karl Pauls (JIRA)]

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

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

I applied the patch in r1811166.

> Improve concurrency in FSDynamicClassLoader
> ---
>
> Key: SLING-7175
> URL: https://issues.apache.org/jira/browse/SLING-7175
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Affects Versions: File System ClassLoader 1.0.6
>Reporter: Karl Pauls
>Assignee: Karl Pauls
> Fix For: File System ClassLoader 1.0.8
>
> Attachments: SLING-7175.patch
>
>
> FSDynamicClassLoader currently maintains two synchronized sets of class names 
> that have been loaded ( a "hit" and a "miss" set). That can be a source of 
> contention when a lot of classes are loaded concurrently. 
> I think we can optimize this somewhat by a) merging the two sets into one (as 
> they are never used independently from what I can tell) and b) using a 
> Collections.newSetFromMap(new ConcurrentHashMap) instead of a 
> Collections.synchronizedSet(new HashSet()). 
> Furthermore, the isDirty boolean flag should be volatile as it might be 
> accessed concurrently. 



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