Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Raymond Auge]

This would be interpreted by a provisioning agent that uses the OSGi
resolver to calculate a requirement closure.

But you know this is not a hard requirement. :)

It's an idea we can add at any time. I don't think it should hold up your
first release.

I, or anyone interested like Christian, can always contribute it at any
point.

So, please don't let this block you on my account.

Cheers,
- Ray

On Sat, Jan 26, 2019 at 10:03 AM Georg Henzler  wrote:

> Hi,
>
> so I'm more than happy to have a @RequireFelixHealthCheck in... I had a
> look at the RequireGogo annotation [1] and usages like [2], I could
> follow that pattern but I'm not sure where this is exactly interpreted
> at the moment as I'm mostly used to the Apache Sling-based provisioning
> mechanism. Is the simple way of starting Felix with "java -jar
> bin/felix.jar" taking those annotations into account? The documentation
> in [3] does not seem to explicitly mention it...
>
> > I just also checked where we could put the annotations. We have the
> > bundles
> > API and annotation.
> > This makes me wonder if we could put the annotations into the API
> > bundle.
> > WDYT?
>
> At the moment the annotations maven module is not a bundle, as it is
> only required at build time by bnd-maven-plugin. To move on with this I
> have to understand how/where annotations like @RequireGogo are
> interpreted :)
>
> -Georg
>
> [1]
>
> https://github.com/apache/felix/blob/trunk/gogo/runtime/src/main/java/org/apache/felix/service/command/annotations/RequireGogo.java
> [2]
>
> https://github.com/apache/felix/blob/trunk/gogo/itest-jline/src/main/java/org/apache/felix/gogo/itest/jline/package-info.java
> [3]
>
> http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.html#starting-the-framework
>
> On 2019-01-26 08:29, Christian Schneider wrote:
> > +1 for a @RequireFelixHealthCheck annotation.
> > I think we then also need an annotation for requiring the health check
> > web
> > console plugin, or do you see a way to automate this when web console
> > is
> > present.
> >
>
> >
> > Christian
> >
> > Am Sa., 26. Jan. 2019 um 00:04 Uhr schrieb Raymond Auge <
> > raymond.a...@liferay.com>:
> >
> >> So, I wasn't suggesting to make an explicit requirement needed for
> >> this,
> >> but rather a convenience annotation similar to
> >>
> >> @RequireJaxrsWhiteboard [1]
> >>
> >> which is an annotation that I can use if I want to assert that the
> >> deployment will calculate that I want a JAXRS whiteboard dpeloyed.
> >>
> >> :)
> >>
> >> This is a way to build a deployment descriptor into what you might
> >> refer to
> >> as an "Application bundle" which might be a package-info.java
> >> containing:
> >>
> >> @RequireJaxrsWhiteboard
> >> @RequireCDIExtender
> >> @RequireGogo
> >> @RequireFelixHealthCheck
> >> package com.acme.application;
> >>
> >> This is in place of having to write out some deployment descriptor
> >> somewhere in like a bndrun or feature file. The resolver can simple
> >> resolve
> >> those from some set of repositories with no other input other than
> >> your
> >> application bundle.
> >>
> >> Sincerely,
> >> - Ray
> >>
> >> [1]
> >>
> >>
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#org.osgi.service.jaxrs.whiteboard.annotations.RequireJaxrsWhiteboard
> >>
> >> On Fri, Jan 25, 2019 at 4:50 PM Georg Henzler 
> >> wrote:
> >>
> >> > Having thought a bit more about this, for most bundles implementing a
> >> > health check it is more of an optional extension. This means
> bundle-XYZ
> >> > primarily will provide the functionality XYZ with an optional health
> >> > check testing state around functionality XYZ in action. Usually you
> >> > would even make the package dependency to org.apache.felix.hc.api
> >> > optional with the result that
> >> >
> >> > - if bundle org.apache.sling.hc.api is *not* available,
> >> >functionality XYZ is still fully working
> >> > - if bundle org.apache.sling.hc.api *is* available,
> >> >functionality XYZ is working and can be checked via provided HC(s)
> >> >
> >> > So I think it's fine to start without an explicitly declared
> capability,
> >> > we can add this easily later if desired.
> >> >
> >> > -Georg
> >> >
> >> >
> >> > On 2019-01-21 15:06, Raymond Auge wrote:
> >> > > On Mon, Jan 21, 2019 at 2:19 AM Georg Henzler 
> >> > > wrote:
> >> > >
> >> > >> Hi Ray,
> >> > >>
> >> > >> so your suggestion is more about referring to a capability like
> >> > >> "org.apache.felix.healthcheck" by using requirements in other
> bundles
> >> > >> than writing a health check that ensures the framework provides a
> >> > >> certain non-healthcheck-related capability.
> >> > >>
> >> > >
> >> > > Precisely,
> >> > >
> >> > > - Ray
> >> > >
> >> > >
> >> > >>
> >> > >> > I can probably try it out and submit the proper cap&req.
> >> > >>
> >> > >> that would be great!
> >> > >>
> >> > >> -Georg
> >> > >>
> >> > >>
> >> >
> >>
> >>
> >> --
> >> *Raymond Augé* 

Re: [DISCUSS] First release of health check modules annotation, api, core, generalchecks and webconsoleplugin

[Georg Henzler]

Hi,

so I'm more than happy to have a @RequireFelixHealthCheck in... I had a 
look at the RequireGogo annotation [1] and usages like [2], I could 
follow that pattern but I'm not sure where this is exactly interpreted 
at the moment as I'm mostly used to the Apache Sling-based provisioning 
mechanism. Is the simple way of starting Felix with "java -jar 
bin/felix.jar" taking those annotations into account? The documentation 
in [3] does not seem to explicitly mention it...


I just also checked where we could put the annotations. We have the 
bundles

API and annotation.
This makes me wonder if we could put the annotations into the API 
bundle.

WDYT?


At the moment the annotations maven module is not a bundle, as it is 
only required at build time by bnd-maven-plugin. To move on with this I 
have to understand how/where annotations like @RequireGogo are 
interpreted :)


-Georg

[1] 
https://github.com/apache/felix/blob/trunk/gogo/runtime/src/main/java/org/apache/felix/service/command/annotations/RequireGogo.java
[2] 
https://github.com/apache/felix/blob/trunk/gogo/itest-jline/src/main/java/org/apache/felix/gogo/itest/jline/package-info.java
[3] 
http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.html#starting-the-framework


On 2019-01-26 08:29, Christian Schneider wrote:

+1 for a @RequireFelixHealthCheck annotation.
I think we then also need an annotation for requiring the health check 
web
console plugin, or do you see a way to automate this when web console 
is

present.





Christian

Am Sa., 26. Jan. 2019 um 00:04 Uhr schrieb Raymond Auge <
raymond.a...@liferay.com>:

So, I wasn't suggesting to make an explicit requirement needed for 
this,

but rather a convenience annotation similar to

@RequireJaxrsWhiteboard [1]

which is an annotation that I can use if I want to assert that the
deployment will calculate that I want a JAXRS whiteboard dpeloyed.

:)

This is a way to build a deployment descriptor into what you might 
refer to
as an "Application bundle" which might be a package-info.java 
containing:


@RequireJaxrsWhiteboard
@RequireCDIExtender
@RequireGogo
@RequireFelixHealthCheck
package com.acme.application;

This is in place of having to write out some deployment descriptor
somewhere in like a bndrun or feature file. The resolver can simple 
resolve
those from some set of repositories with no other input other than 
your

application bundle.

Sincerely,
- Ray

[1]

https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#org.osgi.service.jaxrs.whiteboard.annotations.RequireJaxrsWhiteboard

On Fri, Jan 25, 2019 at 4:50 PM Georg Henzler  
wrote:


> Having thought a bit more about this, for most bundles implementing a
> health check it is more of an optional extension. This means bundle-XYZ
> primarily will provide the functionality XYZ with an optional health
> check testing state around functionality XYZ in action. Usually you
> would even make the package dependency to org.apache.felix.hc.api
> optional with the result that
>
> - if bundle org.apache.sling.hc.api is *not* available,
>functionality XYZ is still fully working
> - if bundle org.apache.sling.hc.api *is* available,
>functionality XYZ is working and can be checked via provided HC(s)
>
> So I think it's fine to start without an explicitly declared capability,
> we can add this easily later if desired.
>
> -Georg
>
>
> On 2019-01-21 15:06, Raymond Auge wrote:
> > On Mon, Jan 21, 2019 at 2:19 AM Georg Henzler 
> > wrote:
> >
> >> Hi Ray,
> >>
> >> so your suggestion is more about referring to a capability like
> >> "org.apache.felix.healthcheck" by using requirements in other bundles
> >> than writing a health check that ensures the framework provides a
> >> certain non-healthcheck-related capability.
> >>
> >
> > Precisely,
> >
> > - Ray
> >
> >
> >>
> >> > I can probably try it out and submit the proper cap&req.
> >>
> >> that would be great!
> >>
> >> -Georg
> >>
> >>
>


--
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance 
(@OSGiAlliance)




--

Re: Add my key to https://dist.apache.org/repos/dist/release/felix/KEYS

[Georg Henzler]

Thanks a lot!

-Georg


On 2019-01-25 23:24, Karl Pauls wrote:

Done.

regards,

Karl

On Fri, Jan 25, 2019 at 11:16 PM Georg Henzler  
wrote:


Looks like the attachment didn't come through, so see [3] for the
contents of toadd.key

On 2019-01-25 23:06, Georg Henzler wrote:
> Hi PMC-members,
>
> could someone please add my key to list [1] as described in the
> release docu [2]? See attached file toadd.key.
>
> Thanks!
> Georg
>

[RESULT] [VOTE] Release Apache Felix Bnd SCR Plugin 1.9.2

[Stefan Seifert]

Hi,

The vote has passed with the following result :

  +1 (binding): Pierre De Rop, Carsten Ziegeler, Raymond Auge, Jean-Baptiste 
Onofré
  +1 (non binding): Stefan Seifert, Francois Papon


=> @any PMC member: please copy this release to the Felix dist directory!


i will then promote the artifacts to the central Maven repository and update 
the felix site.

stefan

[jira] [Closed] (FELIX-6023) SCR bnd plugin sometimes fails with IncompatibleClassChangeError: Implementing class

[Stefan Seifert (JIRA)]

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

Stefan Seifert closed FELIX-6023.
-

> SCR bnd plugin sometimes fails with IncompatibleClassChangeError: 
> Implementing class
> 
>
> Key: FELIX-6023
> URL: https://issues.apache.org/jira/browse/FELIX-6023
> Project: Felix
>  Issue Type: Bug
>  Components: SCR Tooling
>Affects Versions: scr bnd plugin 1.9.0
> Environment: Maven home: /usr/local/Cellar/maven/3.6.0/libexec
> Java version: 1.8.0_192, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_192.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.14.2", arch: "x86_64", family: "mac"
>Reporter: Mark Adamcin
>Assignee: Stefan Seifert
>Priority: Major
>  Labels: patch-available
> Fix For: scr bnd plugin 1.9.2
>
> Attachments: com.adobe.acs.acs-aem-commons-bundle.bnd-1.9.0.log, 
> com.adobe.acs.acs-aem-commons-bundle.bnd-1.9.1-SNAPSHOT.log
>
>
>  
> When building a project where a newer version of a dependency is embedded in 
> the project artifact with a conflicting older version of said dependency is 
> also present on the classpath, SOME environments encounter an exception that 
> is similar to the following:
> {noformat}
> [ERROR] Manifest com.adobe.acs:acs-aem-commons-bundle:bundle:3.19.1-SNAPSHOT 
> : Got unexpected exception while 
> analyzing:org.apache.felix.scrplugin.SCRDescriptorException: Unable to load 
> compiled class: com.google.common.base.Suppliers$SupplierFunctionImpl
>   at 
> org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:156)
>   at 
> org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:146)
>   at 
> org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin.analyzeJar(SCRDescriptorBndPlugin.java:178)
>   at aQute.bnd.osgi.Analyzer.doPlugins(Analyzer.java:820)
>   at aQute.bnd.osgi.Analyzer.analyze(Analyzer.java:229)
>   at aQute.bnd.osgi.Builder.analyze(Builder.java:408)
>   at aQute.bnd.osgi.Analyzer.calcManifest(Analyzer.java:850)
>   at aQute.bnd.osgi.Builder.build(Builder.java:116)
>   at 
> org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer(ManifestPlugin.java:291)
>   at 
> org.apache.felix.bundleplugin.ManifestPlugin.execute(ManifestPlugin.java:98)
>   at 
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:384)
>   at 
> org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:375)
>   at 
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
>   at 
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
>   at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
>   at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
>   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
>   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
>   at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
>   at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: java.lang.IncompatibleClassChangeError: Implementing class
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java