Re: [VOTE] Release Apache Sling Installer Health Checks version 2.0.0

2018-04-09 Thread Daniel Klco
+1

On Mon, Apr 9, 2018 at 5:12 AM, Oliver Lietz  wrote:

> On Friday 06 April 2018 11:51:29 Konrad Windszus wrote:
> > Hi,
> >
> > We solved 2 issues in this release:
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12339841
>
> +1
>
> O.
>
>


[jira] [Resolved] (SLING-7565) Sling Composum shows error 500 on loading on Karaf and Starter

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz resolved SLING-7565.
-
   Resolution: Fixed
Fix Version/s: Starter 11
   Karaf Features 0.2.0

> Sling Composum shows error 500 on loading on Karaf and Starter
> --
>
> Key: SLING-7565
> URL: https://issues.apache.org/jira/browse/SLING-7565
> Project: Sling
>  Issue Type: Bug
>  Components: Karaf, Starter
>Reporter: Purnendra Pratap Singh
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Karaf Features 0.2.0, Starter 11
>
> Attachments: Screen Shot 2018-03-30 at 3.06.35 PM.png
>
>
> After installing Composum feature on Apache Karaf for Sling .
> if I am trying to load /bin/browser.html first time I am seeing error 500 pop 
> up ( see screenshot attached for the error) and same error also comes 
> everytime we click on 'jcr:root' node on the Node Browser 
> 
> [Composum #128 - ClassCastException: java.lang.Integer cannot be cast to 
> java.lang.Long|https://github.com/ist-dresden/composum/issues/128]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (SLING-7576) Update Composum to 1.8.3

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz resolved SLING-7576.
-
Resolution: Done

> Update Composum to 1.8.3
> 
>
> Key: SLING-7576
> URL: https://issues.apache.org/jira/browse/SLING-7576
> Project: Sling
>  Issue Type: Task
>  Components: Karaf, Starter
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Karaf Features 0.2.0, Starter 11
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (SLING-7576) Update Composum to 1.8.3

2018-04-09 Thread Oliver Lietz (JIRA)
Oliver Lietz created SLING-7576:
---

 Summary: Update Composum to 1.8.3
 Key: SLING-7576
 URL: https://issues.apache.org/jira/browse/SLING-7576
 Project: Sling
  Issue Type: Task
  Components: Karaf, Starter
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Karaf Features 0.2.0, Starter 11






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: No mock classes in API documentation?

2018-04-09 Thread Jason E Bailey
Then there's a lack of clarity then in what goes into the published API 
specification. The testing mock is part of Apache Sling, it's hosted and 
developed by this Project. Is there anything that states that the Only API that 
we are publishing is those bundles that are specifically part of the 
launchpad/starter?

If there are first and second class bundles, why aren't they separated out on 
the downloads page for clarification? 

And although I appreciate that you have  the API's available. My personal 
opinion is that an Apache Project should host the API documentation itself and 
not rely on a third party.

- Jason

On Mon, Apr 9, 2018, at 10:10 AM, Stefan Seifert wrote:
> do you mean from sling-mock, osgi-mock, jcr-mock?
> i think it makes sense to not include them in the API docs because they 
> are not available at runtime but only for for test code. and they are 
> not "released" together with the each sling major version, they are not 
> included in the launchpad/starter.
> 
> on the other side the API from those modules (and from other testing 
> modules) are not documented in any published api docs them - not sure if 
> it makes sense to publish a separate "Testing API" docs for them.
> 
> as a workaround you can use [1] which contains the apidocs for the sling 
> mocks as well.
> 
> stefan
> 
> [1] http://wcm.io/testing/aem-mock/apidocs/
> 
> 
> >-Original Message-
> >From: Jason E Bailey [mailto:j...@apache.org]
> >Sent: Sunday, April 1, 2018 4:10 PM
> >To: dev@sling.apache.org
> >Subject: No mock classes in API documentation?
> >
> >Was looking up a class and the last time it was in the API was Sling 6.
> >Was that intentional?
> >- Jason
> >
> 


Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

2018-04-09 Thread Konrad Windszus
I added this requirement now to the newly created 
https://issues.apache.org/jira/browse/SLING-7575 
. We are blocked though by 
https://github.com/bndtools/bnd/issues/2265 
 (until the release of 
bnd-maven-plugin 4.0).
Feel free to extend the list of common bnd instructions which should in the 
future be defined in our parent pom.
Thanks,
Konrad

> On 9. Apr 2018, at 16:30, Justin Edelson  wrote:
> 
> Oh yeah, then that's a problem. It really should be epoch-based IMO.
> 
> On Mon, Apr 9, 2018 at 10:28 AM Konrad Windszus  wrote:
> 
>> By default the timestamp is having the format "MMddHHmm" (
>> http://bnd.bndtools.org/macros/tstamp.html <
>> http://bnd.bndtools.org/macros/tstamp.html>), this could be a problem in
>> certain cases where you redeploy two builds within the same minute.
>> 
>> 
>>> On 9. Apr 2018, at 15:55, Justin Edelson 
>> wrote:
>>> 
>>> I'm not sure this is problematic from the perspective of the installer.
>> The
>>> point of the different SNAPSHOT handling is to support the use case of
>>> updating a bundle with the *same* bundle version. However, if the bundle
>>> versions are including a timestamp, it isn't needed since the bundle
>>> versions would be constantly increasing.
>>> 
>>> Now there could be a problem if the timestamp somehow not taking
>> timezones
>>> into account, but assuming it is UNIX epoch based, then this won't be an
>>> issue.
>>> 
>>> Regards,
>>> Justin
>>> 
>>> On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:
>>> 
 I am just migrating the OSGi Installer HC (
 https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
 bnd-maven-plugin and I observed one difference to the
>> maven-bundle-plugin:
 
 The bundle version for SNAPSHOTs by default looks like
>> "1.0.1."
 instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
 The reason for that is this line:
 
>> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
 wich
 sets the snapshot instruction to the timestamp (
 http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
 SNAPSHOT qualifier in the version being replaced by the timestamp in the
 generated bundle version.
 
 This is IMHO problematic in combination with the OSGi Installer, as that
 behaves differently when it detects a SNAPSHOT (
 
>> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
 ).
 
 Should we configure all our bundles in a way that SNAPSHOT in the
>> version
 is not being replaced, or can we come up with a more intelligent
>> solution
 in the OSGi Installer?
 I noticed that in the manifest we have in addition still
 "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base
>> the
 SNAPSHOT detection of the OSGi Installer.
 
 WDYT?
 Konrad
 
 
 
>> 
>> 



[jira] [Created] (SLING-7575) Define common instructions for bnd-maven-plugin

2018-04-09 Thread Konrad Windszus (JIRA)
Konrad Windszus created SLING-7575:
--

 Summary: Define common instructions for bnd-maven-plugin
 Key: SLING-7575
 URL: https://issues.apache.org/jira/browse/SLING-7575
 Project: Sling
  Issue Type: Improvement
  Components: General
Affects Versions: Parent 33
Reporter: Konrad Windszus
 Fix For: Parent 34


Once [https://github.com/bndtools/bnd/issues/2265] is fixed and released in 
{{bnd-maven-plugin}} 4.0 we should upgrade to that version and make sure to 
define all the instructions common to all Sling bundles in the parameter 
{{bnd}} of the parent. Those instructions should include
 # Bundle-Category: sling
 # Bundle-Description: ${project.description}
 # Bundle-DocURL: https://sling.apache.org|https://sling.apache.org/
 # Bundle-License: Apache License, Version 2.0
 # Bundle-Vendor: The Apache Software Foundation
 # -exportcontents: ${packages;VERSIONED}, this is to by default export all 
versioned packages, compare with [https://github.com/bndtools/bnd/issues/2131]
 # -snapshot: ${tstamp;MMddHHmmssSS} (compare with 
[https://www.mail-archive.com/dev@sling.apache.org/msg76177.html])



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

2018-04-09 Thread Justin Edelson
Oh yeah, then that's a problem. It really should be epoch-based IMO.

On Mon, Apr 9, 2018 at 10:28 AM Konrad Windszus  wrote:

> By default the timestamp is having the format "MMddHHmm" (
> http://bnd.bndtools.org/macros/tstamp.html <
> http://bnd.bndtools.org/macros/tstamp.html>), this could be a problem in
> certain cases where you redeploy two builds within the same minute.
>
>
> > On 9. Apr 2018, at 15:55, Justin Edelson 
> wrote:
> >
> > I'm not sure this is problematic from the perspective of the installer.
> The
> > point of the different SNAPSHOT handling is to support the use case of
> > updating a bundle with the *same* bundle version. However, if the bundle
> > versions are including a timestamp, it isn't needed since the bundle
> > versions would be constantly increasing.
> >
> > Now there could be a problem if the timestamp somehow not taking
> timezones
> > into account, but assuming it is UNIX epoch based, then this won't be an
> > issue.
> >
> > Regards,
> > Justin
> >
> > On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:
> >
> >> I am just migrating the OSGi Installer HC (
> >> https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
> >> bnd-maven-plugin and I observed one difference to the
> maven-bundle-plugin:
> >>
> >> The bundle version for SNAPSHOTs by default looks like
> "1.0.1."
> >> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
> >> The reason for that is this line:
> >>
> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
> >> wich
> >> sets the snapshot instruction to the timestamp (
> >> http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
> >> SNAPSHOT qualifier in the version being replaced by the timestamp in the
> >> generated bundle version.
> >>
> >> This is IMHO problematic in combination with the OSGi Installer, as that
> >> behaves differently when it detects a SNAPSHOT (
> >>
> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
> >> ).
> >>
> >> Should we configure all our bundles in a way that SNAPSHOT in the
> version
> >> is not being replaced, or can we come up with a more intelligent
> solution
> >> in the OSGi Installer?
> >> I noticed that in the manifest we have in addition still
> >> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base
> the
> >> SNAPSHOT detection of the OSGi Installer.
> >>
> >> WDYT?
> >> Konrad
> >>
> >>
> >>
>
>


Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

2018-04-09 Thread Konrad Windszus
By default the timestamp is having the format "MMddHHmm" 
(http://bnd.bndtools.org/macros/tstamp.html 
), this could be a problem in 
certain cases where you redeploy two builds within the same minute.


> On 9. Apr 2018, at 15:55, Justin Edelson  wrote:
> 
> I'm not sure this is problematic from the perspective of the installer. The
> point of the different SNAPSHOT handling is to support the use case of
> updating a bundle with the *same* bundle version. However, if the bundle
> versions are including a timestamp, it isn't needed since the bundle
> versions would be constantly increasing.
> 
> Now there could be a problem if the timestamp somehow not taking timezones
> into account, but assuming it is UNIX epoch based, then this won't be an
> issue.
> 
> Regards,
> Justin
> 
> On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:
> 
>> I am just migrating the OSGi Installer HC (
>> https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
>> bnd-maven-plugin and I observed one difference to the maven-bundle-plugin:
>> 
>> The bundle version for SNAPSHOTs by default looks like "1.0.1."
>> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
>> The reason for that is this line:
>> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
>> wich
>> sets the snapshot instruction to the timestamp (
>> http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
>> SNAPSHOT qualifier in the version being replaced by the timestamp in the
>> generated bundle version.
>> 
>> This is IMHO problematic in combination with the OSGi Installer, as that
>> behaves differently when it detects a SNAPSHOT (
>> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
>> ).
>> 
>> Should we configure all our bundles in a way that SNAPSHOT in the version
>> is not being replaced, or can we come up with a more intelligent solution
>> in the OSGi Installer?
>> I noticed that in the manifest we have in addition still
>> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base the
>> SNAPSHOT detection of the OSGi Installer.
>> 
>> WDYT?
>> Konrad
>> 
>> 
>> 



RE: No mock classes in API documentation?

2018-04-09 Thread Stefan Seifert
do you mean from sling-mock, osgi-mock, jcr-mock?
i think it makes sense to not include them in the API docs because they are not 
available at runtime but only for for test code. and they are not "released" 
together with the each sling major version, they are not included in the 
launchpad/starter.

on the other side the API from those modules (and from other testing modules) 
are not documented in any published api docs them - not sure if it makes sense 
to publish a separate "Testing API" docs for them.

as a workaround you can use [1] which contains the apidocs for the sling mocks 
as well.

stefan

[1] http://wcm.io/testing/aem-mock/apidocs/


>-Original Message-
>From: Jason E Bailey [mailto:j...@apache.org]
>Sent: Sunday, April 1, 2018 4:10 PM
>To: dev@sling.apache.org
>Subject: No mock classes in API documentation?
>
>Was looking up a class and the last time it was in the API was Sling 6.
>Was that intentional?
>- Jason
>



Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

2018-04-09 Thread Justin Edelson
I'm not sure this is problematic from the perspective of the installer. The
point of the different SNAPSHOT handling is to support the use case of
updating a bundle with the *same* bundle version. However, if the bundle
versions are including a timestamp, it isn't needed since the bundle
versions would be constantly increasing.

Now there could be a problem if the timestamp somehow not taking timezones
into account, but assuming it is UNIX epoch based, then this won't be an
issue.

Regards,
Justin

On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:

> I am just migrating the OSGi Installer HC (
> https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
> bnd-maven-plugin and I observed one difference to the maven-bundle-plugin:
>
> The bundle version for SNAPSHOTs by default looks like "1.0.1."
> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
> The reason for that is this line:
> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
> wich
> sets the snapshot instruction to the timestamp (
> http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
> SNAPSHOT qualifier in the version being replaced by the timestamp in the
> generated bundle version.
>
> This is IMHO problematic in combination with the OSGi Installer, as that
> behaves differently when it detects a SNAPSHOT (
> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
> ).
>
> Should we configure all our bundles in a way that SNAPSHOT in the version
> is not being replaced, or can we come up with a more intelligent solution
> in the OSGi Installer?
> I noticed that in the manifest we have in addition still
> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base the
> SNAPSHOT detection of the OSGi Installer.
>
> WDYT?
> Konrad
>
>
>


[RESULT] [VOTE] Release Apache Sling Testing Clients version 1.2.0 and Apache Sling Testing Rules 1.0.8

2018-04-09 Thread Andrei Dulvac
Hi,

The vote has passed with the following result :

+1 (binding): Robert, Konrad, Radu

Thank you all.

Can a member of the PMC help me and copy this release to the Sling
dist directory and promote the artifacts to the central Maven
repository?


- Andrei


Re: [VOTE] Release Apache Sling Testing Clients version 1.2.0 and Apache Sling Testing Rules 1.0.8

2018-04-09 Thread Andrei Dulvac
Thanks all

On Fri, Apr 6, 2018 at 10:16 AM Radu Cotescu  wrote:

> +1
>
> > On 29 Mar 2018, at 13:55, Andrei Dulvac  wrote:
> >
> > 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.
>
>


Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

2018-04-09 Thread Bertrand Delacretaz
Hi,

On Fri, Apr 6, 2018 at 8:32 AM, Konrad Windszus  wrote:
> ...Should we configure all our bundles in a way that SNAPSHOT in the version 
> is not being replaced...

I think we should keep the -SNAPSHOT version suffix as is, for
backwards compatibility reasons.

-Bertrand


Re: [VOTE] Release Apache Sling Installer Health Checks version 2.0.0

2018-04-09 Thread Oliver Lietz
On Friday 06 April 2018 11:51:29 Konrad Windszus wrote:
> Hi,
> 
> We solved 2 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339841

+1

O.



[jira] [Closed] (SLING-7574) Spam

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz closed SLING-7574.
---

> Spam
> 
>
> Key: SLING-7574
> URL: https://issues.apache.org/jira/browse/SLING-7574
> Project: Sling
>  Issue Type: Bug
>Reporter: umemoo
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (SLING-7574) Spam

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-7574:

Summary: Spam  (was: OBAT ASMA)

> Spam
> 
>
> Key: SLING-7574
> URL: https://issues.apache.org/jira/browse/SLING-7574
> Project: Sling
>  Issue Type: Bug
>Reporter: umemoo
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (SLING-7574) OBAT ASMA

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz resolved SLING-7574.
-
Resolution: Invalid

> OBAT ASMA
> -
>
> Key: SLING-7574
> URL: https://issues.apache.org/jira/browse/SLING-7574
> Project: Sling
>  Issue Type: Bug
>Reporter: umemoo
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (SLING-7574) OBAT ASMA

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-7574:

Description: (was: Bagi anda penderita asma di sarankan untuk segera 
melakukan pengobatan dikarenakan apabila dibiarkan penyakit asma  akan 
berkembang hingga menimbulkan peradangan yang parah (asma akut). 
[#https://bit.ly/2GrN3wR] Namun biasanya yang dirasakan pasien asma mengeluhkan 
penyakitnya sering kambuh ketika dirasakan sudah sembuh meskipun sudah 
melakukan pengobatan berbagai cara, hal itu disebabkan obat yang anda konsumsi 
hanya untuk meredakan  gejalanya saja tanpa memnyembuhkan secara tuntas serta 
tidak membunuh bakteri atau virus yang menginfeksi saluran pernafasan sehingga 
bakteri akan kembali menginfeksi organ tersebut.)

> OBAT ASMA
> -
>
> Key: SLING-7574
> URL: https://issues.apache.org/jira/browse/SLING-7574
> Project: Sling
>  Issue Type: Bug
>Reporter: umemoo
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (SLING-7574) OBAT ASMA

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-7574:

External issue URL:   (was: http://razelherbal.id/obat-asma/)

> OBAT ASMA
> -
>
> Key: SLING-7574
> URL: https://issues.apache.org/jira/browse/SLING-7574
> Project: Sling
>  Issue Type: Bug
>Reporter: umemoo
>Priority: Major
>
> Bagi anda penderita asma di sarankan untuk segera melakukan pengobatan 
> dikarenakan apabila dibiarkan penyakit asma  akan berkembang hingga 
> menimbulkan peradangan yang parah (asma akut). [#https://bit.ly/2GrN3wR] 
> Namun biasanya yang dirasakan pasien asma mengeluhkan penyakitnya sering 
> kambuh ketika dirasakan sudah sembuh meskipun sudah melakukan pengobatan 
> berbagai cara, hal itu disebabkan obat yang anda konsumsi hanya untuk 
> meredakan  gejalanya saja tanpa memnyembuhkan secara tuntas serta tidak 
> membunuh bakteri atau virus yang menginfeksi saluran pernafasan sehingga 
> bakteri akan kembali menginfeksi organ tersebut.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (SLING-7574) OBAT ASMA

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz updated SLING-7574:

Component/s: (was: Health Check)

> OBAT ASMA
> -
>
> Key: SLING-7574
> URL: https://issues.apache.org/jira/browse/SLING-7574
> Project: Sling
>  Issue Type: Bug
>Reporter: umemoo
>Priority: Major
>
> Bagi anda penderita asma di sarankan untuk segera melakukan pengobatan 
> dikarenakan apabila dibiarkan penyakit asma  akan berkembang hingga 
> menimbulkan peradangan yang parah (asma akut). [#https://bit.ly/2GrN3wR] 
> Namun biasanya yang dirasakan pasien asma mengeluhkan penyakitnya sering 
> kambuh ketika dirasakan sudah sembuh meskipun sudah melakukan pengobatan 
> berbagai cara, hal itu disebabkan obat yang anda konsumsi hanya untuk 
> meredakan  gejalanya saja tanpa memnyembuhkan secara tuntas serta tidak 
> membunuh bakteri atau virus yang menginfeksi saluran pernafasan sehingga 
> bakteri akan kembali menginfeksi organ tersebut.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (SLING-7253) Upgrade Karaf to 4.2

2018-04-09 Thread Oliver Lietz (JIRA)

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

Oliver Lietz resolved SLING-7253.
-
Resolution: Done

> Upgrade Karaf to 4.2
> 
>
> Key: SLING-7253
> URL: https://issues.apache.org/jira/browse/SLING-7253
> Project: Sling
>  Issue Type: Task
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
> Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
> Karaf Distribution 0.2.0, Karaf Launchpad Integration Tests (Oak Tar) 0.0.2
>
>
> [\[ANN\] Apache Karaf "Container" 4.2.0.M1 has been released 
> !|https://lists.apache.org/thread.html/cb12c5f5bc3c78422a523b44afc23195d9d353e4bd2fd5a62d1baa1c@%3Cdev.karaf.apache.org%3E]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)