[RESULT][VOTE] Apache Karaf Cellar 4.0.5 release

2018-10-14 Thread Jean-Baptiste Onofré
Hi,

this vote passed with the following result:

+1 (binding): Jamie Goodyear, Achim Nierbeck, Jean-Baptiste Onofré
+1 (non binding): François Papon, Serge Huber, Andrea Cosentino

I'm promoting the artifacts on Central and dist.apache.org. I will
update Jira.
When dist is sync, I will announce the release.

Thanks all for your vote.

Regards
JB

On 09/10/2018 17:31, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf Cellar 4.0.5 release to your vote. This release is a
> maintenance release of the Cellar 4.0.x serie.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12340649
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1117/
> 
> Git Tag:
> cellar-4.0.5
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[RESULT][VOTE] Apache Karaf Cellar 4.1.2 release

2018-10-14 Thread Jean-Baptiste Onofré
Hi,

this vote passed with the following result:

+1 (binding): Jamie Goodyear, Achim Nierbeck, Jean-Baptiste Onofré
+1 (non binding): François Papon, Serge Huber, Andrea Cosentino

I'm promoting the artifacts on Central and dist.apache.org. I will
update Jira.
When dist is sync, I will announce the release.

Thanks all for your vote.

Regards
JB

On 10/10/2018 08:05, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf Cellar 4.1.2 release to your vote. This release is a
> maintenance release of the Cellar 4.1.x serie.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12341724
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1118/
> 
> Git Tag:
> cellar-4.1.2
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [VOTE] Apache Karaf Cellar 4.0.5 release

2018-10-12 Thread Jean-Baptiste Onofré
+1 (binding)

Regards
JB

On 09/10/2018 17:31, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf Cellar 4.0.5 release to your vote. This release is a
> maintenance release of the Cellar 4.0.x serie.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12340649
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1117/
> 
> Git Tag:
> cellar-4.0.5
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [VOTE] Apache Karaf Cellar 4.1.2 release

2018-10-12 Thread Jean-Baptiste Onofré
+1 (binding)

Regards
JB

On 10/10/2018 08:05, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf Cellar 4.1.2 release to your vote. This release is a
> maintenance release of the Cellar 4.1.x serie.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12341724
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1118/
> 
> Git Tag:
> cellar-4.1.2
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[VOTE] Apache Karaf Cellar 4.1.2 release

2018-10-10 Thread Jean-Baptiste Onofré
Hi all,

I submit Karaf Cellar 4.1.2 release to your vote. This release is a
maintenance release of the Cellar 4.1.x serie.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12341724

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1118/

Git Tag:
cellar-4.1.2

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[VOTE] Apache Karaf Cellar 4.0.5 release

2018-10-09 Thread Jean-Baptiste Onofré
Hi all,

I submit Karaf Cellar 4.0.5 release to your vote. This release is a
maintenance release of the Cellar 4.0.x serie.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12340649

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1117/

Git Tag:
cellar-4.0.5

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Refused to execute script from 'URL' because its MIME type ('') is not executable, and strict MIME type checking is enabled

2018-10-04 Thread Jean-Baptiste Onofré
Good to know, thanks.

Regards
JB

On 04/10/2018 13:38, munishgupta.asr wrote:
> This was identified as our internal code issue and I was able to resolve it.
> 
> Thanks JB.
> 
> Munish
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [PROPOSAL] Create karaf-4.2.x branch and move master to 4.3.x supporting R7

2018-10-02 Thread Jean-Baptiste Onofré
Just a quick update on this one.

I have a set of local branches that I would like to merge on master
before cutting the 4.2.x branch.
Then I will rebase my R7 update branch.

I keep you posted.

Regards
JB

On 24/09/2018 10:01, Jean-Baptiste Onofré wrote:
> Hi guys,
> 
> based on what Guillaume started already, I moved forward during the week
> end on OSGi R7 support in Karaf.
> 
> I think I will have something fully ready this week (during ApacheCon ;)).
> 
> Once my PR is ready, I propose the following plan:
> 
> - create the karaf-4.2.x branch with the current master
> - bump version on master to 4.3.0-SNAPSHOT and merge the R7 PR
> - "flag" 4.1.x branch as non active
> 
> Thoughts ?
> 
> By the way, I will be at ApacheCon Montréal from tomorrow up to Thursday
> afternoon. If you want to meet, talk about Karaf and related, please let
> me know !
> 
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[INFO] Issue on Jenkins

2018-10-02 Thread Jean-Baptiste Onofré
Hi,

we currently have an issue on Jenkins. It's not related to the Karaf
build itself, it's when Jenkins tries to fetch from github.

It impacts both the nightly build and also the build on Pull Requests.

I'm investigating the issue right now, I keep you posted.

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[PROPOSAL] Create karaf-4.2.x branch and move master to 4.3.x supporting R7

2018-09-24 Thread Jean-Baptiste Onofré
Hi guys,

based on what Guillaume started already, I moved forward during the week
end on OSGi R7 support in Karaf.

I think I will have something fully ready this week (during ApacheCon ;)).

Once my PR is ready, I propose the following plan:

- create the karaf-4.2.x branch with the current master
- bump version on master to 4.3.0-SNAPSHOT and merge the R7 PR
- "flag" 4.1.x branch as non active

Thoughts ?

By the way, I will be at ApacheCon Montréal from tomorrow up to Thursday
afternoon. If you want to meet, talk about Karaf and related, please let
me know !

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Refused to execute script from 'URL' because its MIME type ('') is not executable, and strict MIME type checking is enabled

2018-09-19 Thread Jean-Baptiste Onofré
Hi,

did it work on Karaf 4.1.x ?

Can you share your js ?

Thanks
Regards
JB

On 19/09/2018 14:55, munishgupta.asr wrote:
> Hi All,
> 
> After upgrading KARAF to 4.2.0, I am facing this error while loading JSP
> pages if it loads any custom JS file.
> 
> Refused to execute script from
> 'https://localhost:8443/dashboard/views/welcome.js' because its MIME type
> ('') is not executable, and strict MIME type checking is enabled
> 
> in my JSP page, I am loading this JS file. 
> 
> 
> 
> Has anybody faced this problem before and has any idea about how we can fix
> it?
> 
> Munish
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 


[SECURITY] New security advisory for CVE-2018-11787 released for Apache Karaf

2018-09-18 Thread Jean-Baptiste Onofré
A new security advisory has been released for Apache Karaf, that is
fixed in recent 3.0.9, 4.0.9 and 4.1.1 releases.

CVS-2018-11787: Apache Karaf unsecure access to Gogo shell in the webconsole

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected: all versions of Apache Karaf prior to 3.0.9, 4.0.9,
4.1.1.

Description:

When the webconsole feature is installed in Karaf, it is available at
.../system/console and requires authentication to access it.  One part
of the console is a Gogo shell/console that gives access to the
command line console of Karaf via a Web browser, and when navigated to
it is available at .../system/console/gogo.  Trying to go directly to
that URL does require authentication.

And optional bundle that some applications use is the Pax Web Extender
Whiteboard, it is part of the pax-war feature and perhaps others.
When it is installed, the Gogo console becomes available at another
URL .../gogo/, and that URL is not secured giving access to the Karaf
console to unauthenticated users.

A mitigation for the issue is to manually stop/uninstall Gogo plugin
bundle that is installed with the webconsole feature, although of
course this removes the console from the .../system/console
application, not only from the unauthenticated endpoint.  One could
also stop/uninstall the Pax Web Extender Whiteboard, but other
components/applications may require it and so their functionality
would be reduced/compromised.

This has been fixed in revision:

https://gitbox.apache.org/repos/asf?p=karaf.git;h=cfa213a
https://gitbox.apache.org/repos/asf?p=karaf.git;h=434e525
https://gitbox.apache.org/repos/asf?p=karaf.git;h=1fc60d7

Mitigation: Apache Karaf users should upgrade to 3.0.9, 4.0.9, 4.1.1
or later as soon as possible.

JIRA Tickets: https://issues.apache.org/jira/browse/KARAF-4993

Credit: This issue was reported by Kevin Schmidt


[SECURITY] New security advisory for CVE-2018-11786 released for Apache Karaf

2018-09-18 Thread Jean-Baptiste Onofré
A new security advisory has been released for Apache Karaf, that is
fixed in recent 4.2.0 release.

CVS-2018-11786: Apache Karaf SSH RBAC security enforcement

Severity: Moderate

Vendor: The Apache Software Foundation

Versions Affected: all versions of Apache Karaf prior to 4.2.0.M1

Description:

If the sshd service in Karaf is left on so an administrator can manage
the running instance, any user with rights to the Karaf console can
pivot and read/write any file on the file system to which the Karaf
process user has access. This can be locked down a bit by using chroot
to change the root directory to protect files outside of the Karaf
install directory; it can be further locked down by defining a
security manager policy that limits file system access to those
directories beneath the Karaf home that are necessary for the system
to run. However, this still allows anyone with ssh access to the Karaf
process to read and write a large number of files as the Karaf process
user.


This has been fixed in revision:

https://gitbox.apache.org/repos/asf?p=karaf.git;h=24fb477
https://gitbox.apache.org/repos/asf?p=karaf.git;h=7ad0da3

Mitigation: Apache Karaf users should upgrade to 4.2.0.M1 or later as
soon as possible.

JIRA Tickets: https://issues.apache.org/jira/browse/KARAF-5427

Credit: This issue was reported by R.A. Porter


Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

2018-09-17 Thread Jean-Baptiste Onofré
Hi Lukasz

Good point. In order to avoid to introduce a breaking change, I would
propose to create a feature alias for those URIs.

Regards
JB

On 17/09/2018 14:33, l...@code-house.org wrote:
> Just as an side note - there is an inconsistency in naming of features and 
> their location in repository which doesn’t make whole thing easier.
> 
> Given example of static assemblies we have two URIs: 
> org.apache.karaf.features/framework
> org.apache.karaf.features/static
> where first one contains "framework” feature but second delivers 
> "static-framework”. Such small thing makes it harder to spot how whole thing 
> works. I placed “framework-static” couple of times in my attempts and plugin 
> didn’t protest.
> 
> If we could align these it would make users life a bit easier I guess.
> 
> Cheers,
> Lukasz
> 
>> On 13 Sep 2018, at 14:18, Grzegorz Grzybek  wrote:
>>
>> Hello
>>
>> Thanks JBO for the idea. True - custom distro generation isn't that
>> intuitive as it could be. Personally I missed the flexibility, not
>> simplicity, that's why I added custom in
>> "[KARAF-5468] Cleaning up AssemblyMojo, Profiles and profile Builder".
>>
>> Without it, the implied value for "framework" property was "framework" or
>> "static-framework" depending on whether you had dependency on
>> mvn:org.apache.karaf.features/framework/VERSION/kar or
>> mvn:org.apache.karaf.features/static/VERSION/kar in your POM. The
>> discovered "framework" property was added as "startup feature" which was
>> very confusing (mixing "framework" and "feature" concepts).
>>
>> I can't tell much about improvements for
>> karaf-maven-plugin:features-generate-descriptor, because I always preferred
>> manual creation of feature XMLs.
>>
>> However having dependency on existing karaf distro ("standard" apache-karaf
>> or apache-karaf-minimal) is good idea! karaf-maven-plugin:assembly could
>> search zip or tar.gz or tgz kind of dependencies (with "provided" or any
>> other scope) and:
>> - unpack it
>> - check etc/profile.cfg
>>
>> etc/profile.cfg is (since 4.2.0) nicely written as (official
>> apache-karaf-minimal distro):
>>
>> #
>> # Profile generated by Karaf Assembly Builder
>> #
>>
>> # Parent profiles
>> attribute.parents = generated-startup generated-boot generated-installed
>>
>> # Attributes
>> attribute.overlay = true
>>
>> # Feature XML repositories
>> repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
>> mvn:org.apache.karaf.features/framework/4.2.0/xml/features
>> repository.mvn\:org.apache.karaf.features/standard/4.2.0/xml/features =
>> mvn:org.apache.karaf.features/standard/4.2.0/xml/features
>> repository.mvn\:org.apache.karaf.features/spring/4.2.0/xml/features =
>> mvn:org.apache.karaf.features/spring/4.2.0/xml/features
>>
>> # Features
>> feature.framework = framework
>> feature.jaas = jaas
>> feature.shell = shell
>> feature.feature = feature
>> feature.ssh = ssh
>> feature.bundle = bundle
>> feature.config = config
>> feature.log = log
>>
>> However, with complex distros it can look like this (my distro) - see all
>> the blacklisted items and even special configuration options - these are
>> all generated from pom.xml:
>>
>> #
>> # Profile generated by Karaf Assembly Builder
>> #
>>
>> # Parent profiles
>> attribute.parents = generated-startup generated-boot generated-installed
>>
>> # Attributes
>> attribute.overlay = true
>>
>> # Feature XML repositories
>> repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
>> mvn:org.apache.karaf.features/framework/4.2.0/xml/features
>> ...
>> # Features
>> feature.framework = framework
>> feature.patch-management = patch-management
>> ...
>> feature.pax-jms-config = pax-jms-config
>> feature.pax-jms-pool-narayana = pax-jms-pool-narayana
>> feature.pax-jms-pool-transx = pax-jms-pool-transx
>>
>> # Bundles
>> ...
>> bundle.mvn\:org.bouncycastle/bcprov-jdk15on/1.60 =
>> mvn:org.bouncycastle/bcprov-jdk15on/1.60
>> bundle.mvn\:org.bouncycastle/bcpkix-jdk15on/1.60 =
>> mvn:org.bouncycastle/bcpkix-jdk15on/1.60
>>
>> # Configuration properties for etc/config.properties
>> config.karaf.delay.console = true
>>
>> # Blacklisted repositories
>> blacklisted.repository.mvn\:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
>

Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

2018-09-13 Thread Jean-Baptiste Onofré
Agree, it's what I had in mind and part of the PoC.

Regards
JB

On 14/09/2018 07:13, Freeman Fang wrote:
> yep, that  would be more neat!
> -
> Freeman(Yue) Fang
> 
> Red Hat, Inc. 
> FuseSource is now part of Red Hat
> 
> 
> 
>> On Sep 14, 2018, at 12:03 PM, Francois Papon  
>> wrote:
>>
>> Hi Freeman,
>>
>> Yes I know but we already have some user in the mailing asking for that.
>>
>> I was thinking about including the configuration of property-edits
>> directly in the karaf-maven-plugin configuration.
>>
>> Thoughts ?
>>
>> Regards,
>>
>> François Papon
>> fpa...@apache.org
>>
>> Le 14/09/2018 à 05:39, Freeman Fang a écrit :
>>> Hi François,
>>>
>>> I believe we can already do it to update/add/remove properties in 
>>> configuration files.
>>>
>>> You just need a src/main/karaf/assembly-property-edits.xml like
>>>
>>> http://karaf.apache.org/tools/property-edits/1.0.0;>
>>> 
>>>  
>>>config.properties
>>>put
>>>karaf.framework
>>>equinox
>>>  
>>>  
>>>config.properties
>>>extend
>>>org.osgi.framework.system.capabilities
>>>my-magic-capability
>>>  
>>>  
>>>config.properties
>>>remove
>>>org.apache.karaf.security.providers
>>>  
>>>
>>>
>>>
>>>  
>>>
>>> You can get more details from [1]&[2]
>>> [1]https://issues.apache.org/jira/browse/KARAF-3982
>>> [2]https://issues.apache.org/jira/browse/KARAF-5868
>>> Best Regards
>>>
>>> -
>>> Freeman(Yue) Fang
>>>
>>> Red Hat, Inc. 
>>> FuseSource is now part of Red Hat
>>>
>>>
>>>
>>>> On Sep 13, 2018, at 8:15 PM, Francois Papon  
>>>> wrote:
>>>>
>>>> Hi JB,
>>>>
>>>> I agree about this, we have to focus on the user friendly stuff and I
>>>> have an additional point :
>>>>
>>>> * Add a simple way to update/add properties in the default
>>>>   configuration files of the standard distribution in the assembly
>>>>   (like system.properties)
>>>>
>>>> I'm not sure this is the correct discussion but I think we also have to
>>>> work about helping user to upgrade the Karaf version of their custom
>>>> distributions.
>>>>
>>>> regards,
>>>>
>>>> François Papon
>>>> fpa...@apache.org
>>>>
>>>> Le 13/09/2018 à 15:51, Jean-Baptiste Onofré a écrit :
>>>>> Hi guys,
>>>>>
>>>>> Recently, we received a lot of questions around how to create Karaf
>>>>> custom distribution based on karaf-maven-plugin, and how to use the
>>>>> static profile to create "standalone/static" distribution.
>>>>>
>>>>> If the plugin works fine, it's not easy to understand some "details",
>>>>> like the dependency scope impact, or providing the set of default
>>>>> features repos and features. I already helped users (in private
>>>>> communication) to fix their custom distributions.
>>>>>
>>>>> Obviously, we should simplify the way of creating custom distribution,
>>>>> especially with the new tooling & feature we now provide around Docker.
>>>>>
>>>>> I would like to propose the following:
>>>>>
>>>>> 1. Set the default behavior of the assembly goal to create a custom
>>>>> distribution based on standard. For the user, instead of providing
>>>>> (again) all framework, standard, enterprise features repos and all
>>>>> standard boot features (shell, ...), it will just specify the tar.gz/zip
>>>>> base and his own features repo/repos (or the goal will use the same
>>>>> version of the goal plugin itself). All the rest will be done by the
>>>>> plugin for him. Use the karaf packaging as default to define this. At
>>>>> the end of the day, the user pom.xml will look like:
>>>>>
>>>>> 
>>>>>   foo
>>>>>   bar
>>>>>   1.0-SNAPSHOT
>>>

Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

2018-09-13 Thread Jean-Baptiste Onofré

Good idea !

That makes sense.

Regards
JB

On 13/09/2018 17:27, Francois Papon wrote:

For the template, we can share some templates on the Karaf website like
the feature XSD files ?

For example, a template to create a api rest feature based on Apache CXF.

regards,

François Papon
fpa...@apache.org

Le 13/09/2018 à 19:18, Jean-Baptiste Onofré a écrit :

For the feature generation, I have two ideas that I would like to PoC:

- use a CLI/interactive mode. For instance, if the user runs mvn
karaf:feature-generate, the MOJO will ask some questions. The purpose
is to "abstract" some concepts to simplify for the users.
- additionally, we can imagine to have template (feature-template.xml
or a yaml). The user can provide a template instead of answering
questions (a kind of response file).
- this could be used for bridge the gap with bndtools as well

I would like to PoC this.

Regards
JB

On 13/09/2018 14:18, Grzegorz Grzybek wrote:

Hello

Thanks JBO for the idea. True - custom distro generation isn't that
intuitive as it could be. Personally I missed the flexibility, not
simplicity, that's why I added custom in
"[KARAF-5468] Cleaning up AssemblyMojo, Profiles and profile Builder".

Without it, the implied value for "framework" property was
"framework" or
"static-framework" depending on whether you had dependency on
mvn:org.apache.karaf.features/framework/VERSION/kar or
mvn:org.apache.karaf.features/static/VERSION/kar in your POM. The
discovered "framework" property was added as "startup feature" which was
very confusing (mixing "framework" and "feature" concepts).

I can't tell much about improvements for
karaf-maven-plugin:features-generate-descriptor, because I always
preferred
manual creation of feature XMLs.

However having dependency on existing karaf distro ("standard"
apache-karaf
or apache-karaf-minimal) is good idea! karaf-maven-plugin:assembly could
search zip or tar.gz or tgz kind of dependencies (with "provided" or any
other scope) and:
   - unpack it
   - check etc/profile.cfg

etc/profile.cfg is (since 4.2.0) nicely written as (official
apache-karaf-minimal distro):

#
# Profile generated by Karaf Assembly Builder
#

# Parent profiles
attribute.parents = generated-startup generated-boot generated-installed

# Attributes
attribute.overlay = true

# Feature XML repositories
repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
mvn:org.apache.karaf.features/framework/4.2.0/xml/features
repository.mvn\:org.apache.karaf.features/standard/4.2.0/xml/features =
mvn:org.apache.karaf.features/standard/4.2.0/xml/features
repository.mvn\:org.apache.karaf.features/spring/4.2.0/xml/features =
mvn:org.apache.karaf.features/spring/4.2.0/xml/features

# Features
feature.framework = framework
feature.jaas = jaas
feature.shell = shell
feature.feature = feature
feature.ssh = ssh
feature.bundle = bundle
feature.config = config
feature.log = log

However, with complex distros it can look like this (my distro) - see
all
the blacklisted items and even special configuration options - these are
all generated from pom.xml:

#
# Profile generated by Karaf Assembly Builder
#

# Parent profiles
attribute.parents = generated-startup generated-boot generated-installed

# Attributes
attribute.overlay = true

# Feature XML repositories
repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
mvn:org.apache.karaf.features/framework/4.2.0/xml/features
...
# Features
feature.framework = framework
feature.patch-management = patch-management
...
feature.pax-jms-config = pax-jms-config
feature.pax-jms-pool-narayana = pax-jms-pool-narayana
feature.pax-jms-pool-transx = pax-jms-pool-transx

# Bundles
...
bundle.mvn\:org.bouncycastle/bcprov-jdk15on/1.60 =
mvn:org.bouncycastle/bcprov-jdk15on/1.60
bundle.mvn\:org.bouncycastle/bcpkix-jdk15on/1.60 =
mvn:org.bouncycastle/bcpkix-jdk15on/1.60

# Configuration properties for etc/config.properties
config.karaf.delay.console = true

# Blacklisted repositories
blacklisted.repository.mvn\:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features

= mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
...

# Blacklisted features
blacklisted.feature.httplite = httplite
blacklisted.feature.jetty/[8,9) = jetty/[8,9)
blacklisted.feature.pax-*jetty* = pax-*jetty*
blacklisted.feature.cxf-*-jetty = cxf-*-jetty
...

# Blacklisted bundles
blacklisted.bundle.mvn\:org.ops4j.pax.cdi/pax-cdi-jetty-weld =
mvn:org.ops4j.pax.cdi/pax-cdi-jetty-weld

This etc/profile.cfg can be treated simply as it was added in
karaf-maven-plugin:assembly configuration itself!


  
      path/to/profile.cfg
  


best regards
Grzegorz Grzybek

czw., 13 wrz 2018 o 13:51 Jean-Baptiste Onofré 
napisał(a):


Hi guys,

Recently, we received a lot of questions around how to create Karaf
custom distribution based on karaf-maven-plugin, and how to use the
static profile to

Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

2018-09-13 Thread Jean-Baptiste Onofré

For the feature generation, I have two ideas that I would like to PoC:

- use a CLI/interactive mode. For instance, if the user runs mvn 
karaf:feature-generate, the MOJO will ask some questions. The purpose is 
to "abstract" some concepts to simplify for the users.
- additionally, we can imagine to have template (feature-template.xml or 
a yaml). The user can provide a template instead of answering questions 
(a kind of response file).

- this could be used for bridge the gap with bndtools as well

I would like to PoC this.

Regards
JB

On 13/09/2018 14:18, Grzegorz Grzybek wrote:

Hello

Thanks JBO for the idea. True - custom distro generation isn't that
intuitive as it could be. Personally I missed the flexibility, not
simplicity, that's why I added custom in
"[KARAF-5468] Cleaning up AssemblyMojo, Profiles and profile Builder".

Without it, the implied value for "framework" property was "framework" or
"static-framework" depending on whether you had dependency on
mvn:org.apache.karaf.features/framework/VERSION/kar or
mvn:org.apache.karaf.features/static/VERSION/kar in your POM. The
discovered "framework" property was added as "startup feature" which was
very confusing (mixing "framework" and "feature" concepts).

I can't tell much about improvements for
karaf-maven-plugin:features-generate-descriptor, because I always preferred
manual creation of feature XMLs.

However having dependency on existing karaf distro ("standard" apache-karaf
or apache-karaf-minimal) is good idea! karaf-maven-plugin:assembly could
search zip or tar.gz or tgz kind of dependencies (with "provided" or any
other scope) and:
  - unpack it
  - check etc/profile.cfg

etc/profile.cfg is (since 4.2.0) nicely written as (official
apache-karaf-minimal distro):

#
# Profile generated by Karaf Assembly Builder
#

# Parent profiles
attribute.parents = generated-startup generated-boot generated-installed

# Attributes
attribute.overlay = true

# Feature XML repositories
repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
mvn:org.apache.karaf.features/framework/4.2.0/xml/features
repository.mvn\:org.apache.karaf.features/standard/4.2.0/xml/features =
mvn:org.apache.karaf.features/standard/4.2.0/xml/features
repository.mvn\:org.apache.karaf.features/spring/4.2.0/xml/features =
mvn:org.apache.karaf.features/spring/4.2.0/xml/features

# Features
feature.framework = framework
feature.jaas = jaas
feature.shell = shell
feature.feature = feature
feature.ssh = ssh
feature.bundle = bundle
feature.config = config
feature.log = log

However, with complex distros it can look like this (my distro) - see all
the blacklisted items and even special configuration options - these are
all generated from pom.xml:

#
# Profile generated by Karaf Assembly Builder
#

# Parent profiles
attribute.parents = generated-startup generated-boot generated-installed

# Attributes
attribute.overlay = true

# Feature XML repositories
repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
mvn:org.apache.karaf.features/framework/4.2.0/xml/features
...
# Features
feature.framework = framework
feature.patch-management = patch-management
...
feature.pax-jms-config = pax-jms-config
feature.pax-jms-pool-narayana = pax-jms-pool-narayana
feature.pax-jms-pool-transx = pax-jms-pool-transx

# Bundles
...
bundle.mvn\:org.bouncycastle/bcprov-jdk15on/1.60 =
mvn:org.bouncycastle/bcprov-jdk15on/1.60
bundle.mvn\:org.bouncycastle/bcpkix-jdk15on/1.60 =
mvn:org.bouncycastle/bcpkix-jdk15on/1.60

# Configuration properties for etc/config.properties
config.karaf.delay.console = true

# Blacklisted repositories
blacklisted.repository.mvn\:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
= mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
...

# Blacklisted features
blacklisted.feature.httplite = httplite
blacklisted.feature.jetty/[8,9) = jetty/[8,9)
blacklisted.feature.pax-*jetty* = pax-*jetty*
blacklisted.feature.cxf-*-jetty = cxf-*-jetty
...

# Blacklisted bundles
blacklisted.bundle.mvn\:org.ops4j.pax.cdi/pax-cdi-jetty-weld =
mvn:org.ops4j.pax.cdi/pax-cdi-jetty-weld

This etc/profile.cfg can be treated simply as it was added in
karaf-maven-plugin:assembly configuration itself!


     
 path/to/profile.cfg
 


best regards
Grzegorz Grzybek

czw., 13 wrz 2018 o 13:51 Jean-Baptiste Onofré  napisał(a):


Hi guys,

Recently, we received a lot of questions around how to create Karaf
custom distribution based on karaf-maven-plugin, and how to use the
static profile to create "standalone/static" distribution.

If the plugin works fine, it's not easy to understand some "details",
like the dependency scope impact, or providing the set of default
features repos and features. I already helped users (in private
communication) to fix their custom distributions.

Obviously, we should simplify the way of creating c

Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

2018-09-13 Thread Jean-Baptiste Onofré
Hi,

that's a valid point. What do you think if the karaf-maven-plugin tries
to do a merge ?

I'm also thinking about supporting git repository for resources storage.

Regards
JB

On 13/09/2018 14:15, Francois Papon wrote:
> Hi JB,
> 
> I agree about this, we have to focus on the user friendly stuff and I
> have an additional point :
> 
>   * Add a simple way to update/add properties in the default
> configuration files of the standard distribution in the assembly
> (like system.properties)
> 
> I'm not sure this is the correct discussion but I think we also have to
> work about helping user to upgrade the Karaf version of their custom
> distributions.
> 
> regards,
> 
> François Papon
> fpa...@apache.org
> 
> Le 13/09/2018 à 15:51, Jean-Baptiste Onofré a écrit :
>> Hi guys,
>>
>> Recently, we received a lot of questions around how to create Karaf
>> custom distribution based on karaf-maven-plugin, and how to use the
>> static profile to create "standalone/static" distribution.
>>
>> If the plugin works fine, it's not easy to understand some "details",
>> like the dependency scope impact, or providing the set of default
>> features repos and features. I already helped users (in private
>> communication) to fix their custom distributions.
>>
>> Obviously, we should simplify the way of creating custom distribution,
>> especially with the new tooling & feature we now provide around Docker.
>>
>> I would like to propose the following:
>>
>> 1. Set the default behavior of the assembly goal to create a custom
>> distribution based on standard. For the user, instead of providing
>> (again) all framework, standard, enterprise features repos and all
>> standard boot features (shell, ...), it will just specify the tar.gz/zip
>> base and his own features repo/repos (or the goal will use the same
>> version of the goal plugin itself). All the rest will be done by the
>> plugin for him. Use the karaf packaging as default to define this. At
>> the end of the day, the user pom.xml will look like:
>>
>> 
>>  foo
>>  bar
>>  1.0-SNAPSHOT
>>  karaf
>>
>>  
>>  
>>  org.apache.karaf
>>  apache-karaf
>>  4.2.1
>>  tar.gz
>>  
>>  
>>  foo
>>  my
>>  1.0-SNAPSHOT
>>  features
>>  xml
>>  
>>  
>>
>>  
>>  
>>  
>>  org.apache.karaf.tooling
>> karaf-maven-plugin
>> true
>> true
>> 
>> 
>>  my
>> 
>> 
>>  my-other
>> 
>> 
>>  
>>  
>>  
>>
>> 
>>
>> The idea is to automatically execute install-kar + assembly for the
>> karaf packaging and let the user focus on its own resources (features,
>> config, ...) just providing the base Karaf archive.
>> The user will be able to use src/main/resources to provide any files in
>> etc, bin, or whatever in the resulting custom distribution.
>>
>> 2. Improve a bit the features XML generation
>> If the custom distribution is the highest priority, just after the
>> improvements on this area, I would like to improve the way of creating
>> features XML.
>> Now, to be honest, almost all of us write features repos XML by hand. It
>> gives us the maximum of flexibility. However, on the other hand, the
>> features XML and code contain should be sync.
>> I would like to improve the generate features MOJO, however leveraging
>> most of all functionalities around features (prerequisites, dependency
>> flag, inner features, ...).
>>
>> I have to dig a little bit around that, but if you want some ideas
>> already, please let me know.
>>
>> Thoughts ?
>>
>> Regards
>> JB
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[ANN] Apache Karaf ecanter 2.1.0 has been released !

2018-09-13 Thread Jean-Baptiste Onofré
The Apache Karaf team is pleased to announce Apache Karaf Decanter 2.1.0
release!

This is a major maintenance release on Decanter 2.x series. Especially,
it provides:

* New JDBC collector
* Fix and improvements on the JMS collector and appender
* Upgrade Kafka collector and appender to support Kafka 1.x
* Improvements on the JMX collector to be able to execute MBean operations
* Add new raw and parser services

and much more !

You take a look on the Release Notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342684

Installation instructions and source download are available on the website:

http://karaf.apache.org/download.html

You can also take a look on the update documentation:

http://karaf.apache.org/manual/decanter/latest-2/

Enjoy !

The Apache Karaf Team


Re: [PROPOSAL] Simplify components and cleanup old versions in Jira

2018-09-13 Thread Jean-Baptiste Onofré
By the way, related to the new Docker tooling/feature we added in Karaf
4.2.1, I would like to add a new goal in the karaf-maven-plugin to
directly create a Docker image based on a distribution (like I did in
assemblies/docker/build.sh).

Thoughts ?

Regards
JB

On 09/09/2018 21:03, Jean-Baptiste Onofré wrote:
> Hi team,
> 
> Now, in Jira, we have a bunch of components: karaf-core, karaf-test,
> cellar-config, ...
> 
> Most of the time, when an user creates a Jira, he doesn't set the
> component at all.
> 
> So, the components should be used by us, but obviously, I don't think
> the granularity we have today is helpful.
> 
> I propose the following components:
> 
> - karaf
> - cellar
> - cave
> - decanter
> - website
> 
> That's the core components we manage in the project.
> 
> On the other hand, we have also old versions in Jira, with unreleased
> status.
> 
> I would like to do a cleanup, removing the old versions (not released)
> on branches. If we have Jira issues on this version, I will remove the
> fix version (or even close the issue).
> 
> Thoughts ?
> 
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [PROPOSAL] Simplify components and cleanup old versions in Jira

2018-09-13 Thread Jean-Baptiste Onofré
Hi,

following this discussion, I'm updating Jira components.

Thanks !
Regards
JB

On 09/09/2018 21:03, Jean-Baptiste Onofré wrote:
> Hi team,
> 
> Now, in Jira, we have a bunch of components: karaf-core, karaf-test,
> cellar-config, ...
> 
> Most of the time, when an user creates a Jira, he doesn't set the
> component at all.
> 
> So, the components should be used by us, but obviously, I don't think
> the granularity we have today is helpful.
> 
> I propose the following components:
> 
> - karaf
> - cellar
> - cave
> - decanter
> - website
> 
> That's the core components we manage in the project.
> 
> On the other hand, we have also old versions in Jira, with unreleased
> status.
> 
> I would like to do a cleanup, removing the old versions (not released)
> on branches. If we have Jira issues on this version, I will remove the
> fix version (or even close the issue).
> 
> Thoughts ?
> 
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

2018-09-13 Thread Jean-Baptiste Onofré
Thanks for your feedback Greg.

I started a new local branch with "new" karaf-maven-plugin custom
distribution approach. This branch also contains an example.

I will create a corresponding PR and an update on the mailing list to be
able to discuss all together.

Regards
JB

On 13/09/2018 14:18, Grzegorz Grzybek wrote:
> Hello
> 
> Thanks JBO for the idea. True - custom distro generation isn't that
> intuitive as it could be. Personally I missed the flexibility, not
> simplicity, that's why I added custom in
> "[KARAF-5468] Cleaning up AssemblyMojo, Profiles and profile Builder".
> 
> Without it, the implied value for "framework" property was "framework" or
> "static-framework" depending on whether you had dependency on
> mvn:org.apache.karaf.features/framework/VERSION/kar or
> mvn:org.apache.karaf.features/static/VERSION/kar in your POM. The
> discovered "framework" property was added as "startup feature" which was
> very confusing (mixing "framework" and "feature" concepts).
> 
> I can't tell much about improvements for
> karaf-maven-plugin:features-generate-descriptor, because I always preferred
> manual creation of feature XMLs.
> 
> However having dependency on existing karaf distro ("standard" apache-karaf
> or apache-karaf-minimal) is good idea! karaf-maven-plugin:assembly could
> search zip or tar.gz or tgz kind of dependencies (with "provided" or any
> other scope) and:
>  - unpack it
>  - check etc/profile.cfg
> 
> etc/profile.cfg is (since 4.2.0) nicely written as (official
> apache-karaf-minimal distro):
> 
> #
> # Profile generated by Karaf Assembly Builder
> #
> 
> # Parent profiles
> attribute.parents = generated-startup generated-boot generated-installed
> 
> # Attributes
> attribute.overlay = true
> 
> # Feature XML repositories
> repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
> mvn:org.apache.karaf.features/framework/4.2.0/xml/features
> repository.mvn\:org.apache.karaf.features/standard/4.2.0/xml/features =
> mvn:org.apache.karaf.features/standard/4.2.0/xml/features
> repository.mvn\:org.apache.karaf.features/spring/4.2.0/xml/features =
> mvn:org.apache.karaf.features/spring/4.2.0/xml/features
> 
> # Features
> feature.framework = framework
> feature.jaas = jaas
> feature.shell = shell
> feature.feature = feature
> feature.ssh = ssh
> feature.bundle = bundle
> feature.config = config
> feature.log = log
> 
> However, with complex distros it can look like this (my distro) - see all
> the blacklisted items and even special configuration options - these are
> all generated from pom.xml:
> 
> #
> # Profile generated by Karaf Assembly Builder
> #
> 
> # Parent profiles
> attribute.parents = generated-startup generated-boot generated-installed
> 
> # Attributes
> attribute.overlay = true
> 
> # Feature XML repositories
> repository.mvn\:org.apache.karaf.features/framework/4.2.0/xml/features =
> mvn:org.apache.karaf.features/framework/4.2.0/xml/features
> ...
> # Features
> feature.framework = framework
> feature.patch-management = patch-management
> ...
> feature.pax-jms-config = pax-jms-config
> feature.pax-jms-pool-narayana = pax-jms-pool-narayana
> feature.pax-jms-pool-transx = pax-jms-pool-transx
> 
> # Bundles
> ...
> bundle.mvn\:org.bouncycastle/bcprov-jdk15on/1.60 =
> mvn:org.bouncycastle/bcprov-jdk15on/1.60
> bundle.mvn\:org.bouncycastle/bcpkix-jdk15on/1.60 =
> mvn:org.bouncycastle/bcpkix-jdk15on/1.60
> 
> # Configuration properties for etc/config.properties
> config.karaf.delay.console = true
> 
> # Blacklisted repositories
> blacklisted.repository.mvn\:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
> = mvn:org.ops4j.pax.cdi/pax-cdi-features/1.0.0.RC1/xml/features
> ...
> 
> # Blacklisted features
> blacklisted.feature.httplite = httplite
> blacklisted.feature.jetty/[8,9) = jetty/[8,9)
> blacklisted.feature.pax-*jetty* = pax-*jetty*
> blacklisted.feature.cxf-*-jetty = cxf-*-jetty
> ...
> 
> # Blacklisted bundles
> blacklisted.bundle.mvn\:org.ops4j.pax.cdi/pax-cdi-jetty-weld =
> mvn:org.ops4j.pax.cdi/pax-cdi-jetty-weld
> 
> This etc/profile.cfg can be treated simply as it was added in
> karaf-maven-plugin:assembly configuration itself!
> 
> 
> 
> path/to/profile.cfg
> 
> 
> 
> best regards
> Grzegorz Grzybek
> 
> czw., 13 wrz 2018 o 13:51 Jean-Baptiste Onofré  napisał(a):
> 
>> Hi guys,
>>
>> Recently, we received a lot of questions around how to create Karaf
>> custom distribution based on karaf-maven-plugin, and how to use the
>>

[PROPOSAL] Simplify the karaf-maven-plugin to easily create custom distribution

2018-09-13 Thread Jean-Baptiste Onofré
Hi guys,

Recently, we received a lot of questions around how to create Karaf
custom distribution based on karaf-maven-plugin, and how to use the
static profile to create "standalone/static" distribution.

If the plugin works fine, it's not easy to understand some "details",
like the dependency scope impact, or providing the set of default
features repos and features. I already helped users (in private
communication) to fix their custom distributions.

Obviously, we should simplify the way of creating custom distribution,
especially with the new tooling & feature we now provide around Docker.

I would like to propose the following:

1. Set the default behavior of the assembly goal to create a custom
distribution based on standard. For the user, instead of providing
(again) all framework, standard, enterprise features repos and all
standard boot features (shell, ...), it will just specify the tar.gz/zip
base and his own features repo/repos (or the goal will use the same
version of the goal plugin itself). All the rest will be done by the
plugin for him. Use the karaf packaging as default to define this. At
the end of the day, the user pom.xml will look like:


foo
bar
1.0-SNAPSHOT
karaf



org.apache.karaf
apache-karaf
4.2.1
tar.gz


foo
my
1.0-SNAPSHOT
features
xml






org.apache.karaf.tooling
karaf-maven-plugin
true
true


my


my-other








The idea is to automatically execute install-kar + assembly for the
karaf packaging and let the user focus on its own resources (features,
config, ...) just providing the base Karaf archive.
The user will be able to use src/main/resources to provide any files in
etc, bin, or whatever in the resulting custom distribution.

2. Improve a bit the features XML generation
If the custom distribution is the highest priority, just after the
improvements on this area, I would like to improve the way of creating
features XML.
Now, to be honest, almost all of us write features repos XML by hand. It
gives us the maximum of flexibility. However, on the other hand, the
features XML and code contain should be sync.
I would like to improve the generate features MOJO, however leveraging
most of all functionalities around features (prerequisites, dependency
flag, inner features, ...).

I have to dig a little bit around that, but if you want some ideas
already, please let me know.

Thoughts ?

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[ANN] Apache Karaf Cave 4.1.1 has been released !

2018-09-11 Thread Jean-Baptiste Onofré
The Apache Karaf team is pleased to announce Apache Karaf Cave 4.1.1 
release!


Apache Karaf Cave 4.1.1 is a major update on the 4.1.x series. 
Especially, it brings:


* better Maven repository management
* better Feature Gateway integration
* fixes on the repository and deployer REST API

You take a look on the Release Notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342356

Installation instructions and source download are available on the website:

http://karaf.apache.org/download.html

You can also take a look on the update documentation:

http://karaf.apache.org/manual/cave/latest-4/

Enjoy !

The Apache Karaf Team


[RESULT][VOTE] Apache Karaf Decanter 2.1.0 release

2018-09-11 Thread Jean-Baptiste Onofré
Hi guys,

this vote passed with the following result:

+1 (binding): Jean-Baptiste Onofré, Achim Nierbeck, Jamie Goodyear
+1 (non binding): François Papon

I'm promoting the artifacts on Central, and all actions after the release.

Thanks all for your vote !

Regards
JB

On 07/09/2018 17:33, Jean-Baptiste Onofré wrote:
> Hi,
> 
> I submit Apache Karaf Decanter 2.1.0 release to your vote.
> 
> This is a major maintenance release on Decanter 2.x series. Especially,
> it provides:
> 
> * New JDBC collector
> * Fix and improvements on the JMS collector and appender
> * Upgrade Kafka collector and appender to support Kafka 1.x
> * Improvements on the JMX collector to be able to execute MBean operations
> * Add new raw and parser services
> and much more !
> 
> For complete details, please take a look on the release notes:
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342684
> 
> Git tag:
> decanter-2.1.0
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1116/
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [VOTE] Apache Karaf Decanter 2.1.0 release

2018-09-11 Thread Jean-Baptiste Onofré
+1 (binding)

Gently reminder for this vote.

Regards
JB

On 07/09/2018 17:33, Jean-Baptiste Onofré wrote:
> Hi,
> 
> I submit Apache Karaf Decanter 2.1.0 release to your vote.
> 
> This is a major maintenance release on Decanter 2.x series. Especially,
> it provides:
> 
> * New JDBC collector
> * Fix and improvements on the JMS collector and appender
> * Upgrade Kafka collector and appender to support Kafka 1.x
> * Improvements on the JMX collector to be able to execute MBean operations
> * Add new raw and parser services
> and much more !
> 
> For complete details, please take a look on the release notes:
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342684
> 
> Git tag:
> decanter-2.1.0
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1116/
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: PR608 - Updated Scheduler feature to support persistence - Failed

2018-09-11 Thread Jean-Baptiste Onofré
Hi,

Jenkins is doing the same as local.

Just do a complete:

mvn clean install -Prat

you will have the same.

Regards
JB

On 11/09/2018 10:58, Miroslav Beranič wrote:
> Hi François,
> 
> I have to be logged in to access
> https://builds.apache.org/view/K/view/Karaf/job/karaf-pr/ws/target/karaf-4.2.2-SNAPSHOT.rat/*view*/
> 
> Is registration open or I need invite? I did not see a registration form.
> 
> But more important:
> 
> How do I compile locally in a way, to have this error before pushing to
> Apache's Jenkins - save me embarrassment and you resources on servers.
> 
> Regards,
> Miroslav
> 
> 
> V V tor., 11. sep. 2018 ob 08:46 je oseba Francois Papon <
> francois.pa...@openobject.fr> napisala:
> 
>> Hi,
>>
>> You are missing the Apache License header in files :
>>
>> 4 Unknown Licenses
>>
>> *
>>
>> Files with unapproved licenses:
>>
>>   scheduler/src/main/java/org/apache/karaf/scheduler/SchedulerStorage.java
>>
>> scheduler/src/main/java/org/apache/karaf/scheduler/core/StdOsgiScheduler.java
>>
>> scheduler/src/main/java/org/apache/karaf/scheduler/core/QuartzSchedulerStorage.java
>>
>> scheduler/src/main/java/org/apache/karaf/scheduler/core/StdOsgiSchedulerFactory.java
>>
>> I put some comments on your PR ;)
>>
>> You can see the detailed files here :
>>
>>
>> https://builds.apache.org/view/K/view/Karaf/job/karaf-pr/ws/target/karaf-4.2.2-SNAPSHOT.rat/*view*/
>>
>> regards,
>>
>> François Papon
>> fpa...@apache.org
>>
>> Le 11/09/2018 à 10:35, Miroslav Beranič a écrit :
>>> Hi,
>>>
>>> I've subscribed to dev mailing list.
>>>
>>> I've submitted a pull request at
>> https://github.com/apache/karaf/pull/608,
>>> but I see Jenkins build failed do to:
>>> Caused by: org.apache.rat.mp.RatCheckException: Too many files with
>>> unapproved license: 4 See RAT report in:
>>>
>> /home/jenkins/jenkins-slave/workspace/karaf-pr/target/karaf-4.2.2-SNAPSHOT.rat
>>>
>>>
>>> located at :
>>> https://builds.apache.org/job/karaf-pr/665/console
>>>
>>> What should I update, to make this work?
>>>
>>> Kind Regards,
>>> Miroslav
>>>
>>>
>>
>>
>>
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Scheduler Service to support/expose native Quartz

2018-09-11 Thread Jean-Baptiste Onofré
Hi,

So, I propose two actions:

1. Let me take a look on the PR and see how we can extend the Karaf
Scheduler API, still with Quartz "hidden"
2. I think in your case, you can create your own Scheduler using Quartz.
That would gives you complete control if (1) is not fully convenient for
you. I would be more than happy to help on this one.

Regards
JB

On 11/09/2018 10:27, Miroslav Beranič wrote:
> Hi JB,
> 
> yes, I thought about this - and agree, this change is not all that
> favorable for main-stream Karaf implementation.
> 
> I did not look at camel-quartz, will look it up - thanks.
> 
> One note though - in my "solution" Karaf imports Quartz, not exports, but
> either way, I know what you mean.
> 
> Regards,
> Miroslav
> 
> 
> 
> V V tor., 11. sep. 2018 ob 10:19 je oseba Jean-Baptiste Onofré <
> j...@nanthrax.net> napisala:
> 
>> Hi,
>>
>> I don't think this approach is the good one.
>>
>> Quartz is an implementation of the Karaf Scheduler, but we can imagine
>> other implementations.
>>
>> That's why the Quartz packages are not directly exported by the Karaf
>> Scheduler (it's private package). That's really my main concern: Karaf
>> scheduler should not export or be tight to Quartz.
>>
>> If you want to create your own scheduler, than you can directly use the
>> Quartz bundle, like camel-quartz for instance.
>> Is it not what you need ?
>>
>> On the other hand, I think we can improve/extend the Karaf scheduler
>> API. I already changed it in Karaf 4.2.x but I think we can move forward
>> on this.
>>
>> Regards
>> JB
>>
>> On 11/09/2018 09:09, Miroslav Beranič wrote:
>>> Hi guys,
>>>
>>> I am porting multiple existing production backend/middlware systems from
>>> Tomcat/JBoss to Karaf.
>>>
>>> At first I had issues with JPA+Hibernate, seems to be work now. Now I
>> have
>>> task to migrate existing Quartz 1.8.x code to 2.2.x. At first look I
>>> thought all is done in Karaf, also Quartz was a dependency - and example
>>> looked really simple.
>>>
>>> Here I do not know what is a common guideline in Karaf : Is it good to
>>> support "native" API or is more in favor to implement "common" API. My
>>> decision was, to move to support native Quartz API , as it is really
>> "well
>>> done" and has all and more any one should need.
>>>
>>> So here I will explain why I've decided to update Scheduler service and
>> how
>>> ( in general ) I did it. I am working on last few changes, before I push
>> to
>>> forked github repository.
>>> Repository & branch is already online and anyone can check it out, but it
>>> is not final - I have few more errors needed to be fixed.
>> Repository
>>> location is:
>>>
>>> https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api
>>>
>>> What I've changed:
>>>
>>> 1.) in existing scheduler/pom.xml I've changed so no Quartz package is
>>> private package - stored inside a Scheduler bundle, but all Quartz
>>> dependencies are pulled from existing ServiceMix Quartz bundle:
>>>
>>>
>> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.quartz/2.2.4-SNAPSHOT
>>>
>>> 2.) I extracted interfaces for QuartzScheduler ( Karaf's Scheduler Quartz
>>> wrapper ) so it can be exposed, also for other exposed classes.
>>>
>>> 3.) Exporting all the packages inside Scheduler bundle. This is not
>>> something I am really happy about, but when I was trying to go around
>> this,
>>> I had more problems than benefits.
>>>
>>> 4.) Made all data passed to "datamap" as Serializable, as Quartz as RAM
>>> Storage most of the time only for fun, I guess most of the real usage is
>>> using some kind of persistence - SQL DB - as this is also my case, I had
>> to
>>> support this.
>>>
>>> 5.) I bypass almost all existing "wrapping" code as this introduced
>>> complexity at only additional cost -- when I talk about support for
>> "native
>>> Quartz API".
>>>
>>> So now I can write Quartz producer as :
>>>
>>> @Component
>>> public class KarafSchedulerQuartzJobProducer {
>>>
>>> private final Logger log = LoggerFactory.getLogger(getClass());
>>>
>>> @Reference
>>> private Scheduler scheduler;
>>>
>>

Re: Scheduler Service to support/expose native Quartz

2018-09-11 Thread Jean-Baptiste Onofré
text context) {
> final JobDataMap jobDataMap =
> context.getJobDetail().getJobDataMap();
> 
> message = jobDataMap.getString("message");
> log.info(message);
> 
> }
> 
> }
> 
> So to me this is great solution , as I can now quite easy migrate existing
> source. What I am asking now is: how good solution would this be for Karaf
> - as this makes Scheduler service "bound" to Quartz API, but this is only
> if you need it -- all existing API is still working and was not changes -
> API not, but in the section where data is passed to Quartz any
> non-serializable data was moved to temporary storage and than before
> calling Runnable task re-attached back again, so producer and consumer do
> not really know for any change.
> 
> 
> But all is not all that good, at it might seem. To me this perfect
> solution, but I know it can be made better - more robust/general.
> 
> What are the problems:
> 
> 1.) Quartz is loading classes - so it needs to know where they are. I
> needed quite some time, knocks at the wall and coffee cups to figure this
> out. ( I am not OSGi expert ). So my solution was, to agree on a common
> package, where all Quartz Jobs must be. To me this is issue, but issue I
> can handle - for now.
> 
> Package I've decided for is: org.apache.karaf.scheduler.quartz.job
> 
> a.) To make this work, I have to update ServiceMix Quartz bundle:
> mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.quartz/2.2.4-SNAPSHOT
> was updated to import package org.apache.karaf.scheduler.quartz.job
> 
> b.) Karaf Scheduler Core imports package
> org.apache.karaf.scheduler.quartz.job
> 
> c.) Quartz producer exports org.apache.karaf.scheduler.quartz.job - but I
> also scan for sub-packages, so I guess jobs should be in sub-packages, to
> avoid conflicts.
> 
> This is one part of my changes, I would really like better one, but for
> what I need, this is ok -- and after all the headaches I am quite happy
> with this.
> 
> Example code is located at:
> https://github.com/mibesis/karaf/tree/karaf-4.2.2-scheduler-quartz-api/examples/karaf-scheduler-example/karaf-scheduler-example-quartz
> 
> but ( again ) this is not yet final commit, as I have few more errors to
> fix, but I think not a show stoppers ( I hope ).
> 
> So my final thoughts/questions:
> 
> 1.) Is such a change welcome at Karaf - is this something that would
> benefit Karaf?
> 
> 2.) Is there any other existing solution, I should know of?
> 
> 3.) How can I implement "dynamic" package - so that Quartz job can be in
> any package, but just pre-defined ones.
> 
> Kind regards,
> Miroslav
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: PR608 - Updated Scheduler feature to support persistence - Failed

2018-09-11 Thread Jean-Baptiste Onofré
Hi,

Catcha. I will provide my comments directly in the PR.

Regards
JB

On 11/09/2018 09:12, Miroslav Beranič wrote:
> Hi JB,
> 
> yes, I know. I need Quartz API, so this was my main motivation. I guess not
> all changes are valid.
> Open for any suggestion, let me know.
> 
> Regards,
> Miroslav
> 
> 
> V V tor., 11. sep. 2018 ob 08:49 je oseba Jean-Baptiste Onofré <
> j...@nanthrax.net> napisala:
> 
>> Hi,
>>
>> The ASF headers are missing.
>>
>> By the way, I see a lot of incoherent changes here and not good IMHO.
>>
>> I will do a complete review.
>>
>> Regards
>> JB
>>
>> On 11/09/2018 08:35, Miroslav Beranič wrote:
>>> Hi,
>>>
>>> I've subscribed to dev mailing list.
>>>
>>> I've submitted a pull request at
>> https://github.com/apache/karaf/pull/608,
>>> but I see Jenkins build failed do to:
>>> Caused by: org.apache.rat.mp.RatCheckException: Too many files with
>>> unapproved license: 4 See RAT report in:
>>>
>> /home/jenkins/jenkins-slave/workspace/karaf-pr/target/karaf-4.2.2-SNAPSHOT.rat
>>>
>>>
>>> located at :
>>> https://builds.apache.org/job/karaf-pr/665/console
>>>
>>> What should I update, to make this work?
>>>
>>> Kind Regards,
>>> Miroslav
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: PR608 - Updated Scheduler feature to support persistence - Failed

2018-09-11 Thread Jean-Baptiste Onofré
Hi,

The ASF headers are missing.

By the way, I see a lot of incoherent changes here and not good IMHO.

I will do a complete review.

Regards
JB

On 11/09/2018 08:35, Miroslav Beranič wrote:
> Hi,
> 
> I've subscribed to dev mailing list.
> 
> I've submitted a pull request at https://github.com/apache/karaf/pull/608,
> but I see Jenkins build failed do to:
> Caused by: org.apache.rat.mp.RatCheckException: Too many files with
> unapproved license: 4 See RAT report in:
> /home/jenkins/jenkins-slave/workspace/karaf-pr/target/karaf-4.2.2-SNAPSHOT.rat
> 
> 
> located at :
> https://builds.apache.org/job/karaf-pr/665/console
> 
> What should I update, to make this work?
> 
> Kind Regards,
> Miroslav
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[HEADS UP] Periodical release schedule

2018-09-10 Thread Jean-Baptiste Onofré
Hi guys,

as proposed and discussed in another thread, I updated the release schedule:

http://karaf.apache.org/download.html

The idea is to have a release stable pace: a release every 3 months max
(if of course, the targeted branch contains changes).

So, to summarize, I will do the following releases:

- Karaf Container:
- 4.1.7 on 16 Nov 18
- 4.2.2 on 23 Nov 18
- Karaf Cellar
- 4.0.5 on 5 Oct 18
- 4.1.2 on 5 Oct 18
- Karaf Cave
- 4.1.2 on 8 Dec 18
- Karaf Decanter
- 2.2.0 on 14 Dec 18 (assuming the current vote for 2.1.0 pass)

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[RESULT][VOTE] Apache Karaf Cave 4.1.1 release

2018-09-10 Thread Jean-Baptiste Onofré
Hi,

this vote passed with the following results:

+1 (binding): Jean-Baptiste Onofré, Christian Schneider, Jamie Goodyear
+1 (non binding): François Papon, Grzegorz Grzybek, Andrea Cosentino

I'm promoting the artifacts on Central, update Jira and I will
review/merge the website PR announcing Cave 4.1.1.

Thanks all for your vote.

Regards
JB

On 05/09/2018 06:56, Jean-Baptiste Onofré wrote:
> Hi,
> 
> I submit Apache Karaf Cave 4.1.1 release to your vote.
> 
> This is a maintenance release on Cave 4.1.x series (working on Karaf
> 4.0.x, 4.1.x and 4.2.x), before starting the upgrade to the next 4.2.x
> series.
> This release contains fixes on the Maven repository management, the
> Feature gateway, the REST services (for both repository and deployer).
> 
> For complete details, please take a look on the release notes:
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342356
> 
> Git tag:
> cave-4.1.1
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1115/
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [PROPOSAL] Simplify components and cleanup old versions in Jira

2018-09-09 Thread Jean-Baptiste Onofré
Hi,

So, by karaf-build, you mean both issues targeted on the build tooling
we provide and the build itself.

My point is: what's the difference if these issues are in the karaf
component ? Is it really helpful for us or our users to have karaf-build
component (used in filter for instance) ?

Personally, I have filter using fixVersion (to prepare release content),
but I never use component.

Regards
JB

On 10/09/2018 07:05, Grzegorz Grzybek wrote:
> pon., 10 wrz 2018 o 06:40 Francois Papon 
> napisał(a):
> 
>> Hi Grzegorz,
>>
>> Can you explain why you think it would be nice to have a maven or build
>> component ?
>>
> 
> I was just thinking about distinguishing between runtime and buildtime
> issues.
> Looking at the components[1], I see karaf-tooling has 49 issues - not that
> much comparing to karaf-features or karaf-core.
> So I don't think "build" component is that crucial after all.
> 
> regards
> Grzegorz Grzybek
> ---
> [1]: https://issues.apache.org/jira/projects/KARAF/summary/statistics
> 
> 
>> regards,
>>
>> François Papon
>> fpa...@apache.org
>>
>> Le 10/09/2018 à 08:34, Grzegorz Grzybek a écrit :
>>> Hello
>>>
>>> That'd be great to have fewer components. However, maybe it would be good
>>> to have a component like "maven" or "build" too?
>>>
>>> regards
>>> Grzegorz Grzybek
>>>
>>> pon., 10 wrz 2018 o 04:54 Francois Papon 
>>> napisał(a):
>>>
>>>> Hi JB,
>>>>
>>>> +1 !
>>>>
>>>> Full agree with that :)
>>>>
>>>> regards,
>>>>
>>>> François Papon
>>>> fpa...@apache.org
>>>>
>>>> Le 09/09/2018 à 23:03, Jean-Baptiste Onofré a écrit :
>>>>> Hi team,
>>>>>
>>>>> Now, in Jira, we have a bunch of components: karaf-core, karaf-test,
>>>>> cellar-config, ...
>>>>>
>>>>> Most of the time, when an user creates a Jira, he doesn't set the
>>>>> component at all.
>>>>>
>>>>> So, the components should be used by us, but obviously, I don't think
>>>>> the granularity we have today is helpful.
>>>>>
>>>>> I propose the following components:
>>>>>
>>>>> - karaf
>>>>> - cellar
>>>>> - cave
>>>>> - decanter
>>>>> - website
>>>>>
>>>>> That's the core components we manage in the project.
>>>>>
>>>>> On the other hand, we have also old versions in Jira, with unreleased
>>>>> status.
>>>>>
>>>>> I would like to do a cleanup, removing the old versions (not released)
>>>>> on branches. If we have Jira issues on this version, I will remove the
>>>>> fix version (or even close the issue).
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> Regards
>>>>> JB
>>>>
>>
>>
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[PROPOSAL] Simplify components and cleanup old versions in Jira

2018-09-09 Thread Jean-Baptiste Onofré
Hi team,

Now, in Jira, we have a bunch of components: karaf-core, karaf-test,
cellar-config, ...

Most of the time, when an user creates a Jira, he doesn't set the
component at all.

So, the components should be used by us, but obviously, I don't think
the granularity we have today is helpful.

I propose the following components:

- karaf
- cellar
- cave
- decanter
- website

That's the core components we manage in the project.

On the other hand, we have also old versions in Jira, with unreleased
status.

I would like to do a cleanup, removing the old versions (not released)
on branches. If we have Jira issues on this version, I will remove the
fix version (or even close the issue).

Thoughts ?

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[VOTE] Apache Karaf Decanter 2.1.0 release

2018-09-07 Thread Jean-Baptiste Onofré
Hi,

I submit Apache Karaf Decanter 2.1.0 release to your vote.

This is a major maintenance release on Decanter 2.x series. Especially,
it provides:

* New JDBC collector
* Fix and improvements on the JMS collector and appender
* Upgrade Kafka collector and appender to support Kafka 1.x
* Improvements on the JMX collector to be able to execute MBean operations
* Add new raw and parser services
and much more !

For complete details, please take a look on the release notes:

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342684

Git tag:
decanter-2.1.0

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1116/

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [VOTE] Apache Karaf Cave 4.1.1 release

2018-09-05 Thread Jean-Baptiste Onofré
+1 (binding)

Regards
JB

On 05/09/2018 06:56, Jean-Baptiste Onofré wrote:
> Hi,
> 
> I submit Apache Karaf Cave 4.1.1 release to your vote.
> 
> This is a maintenance release on Cave 4.1.x series (working on Karaf
> 4.0.x, 4.1.x and 4.2.x), before starting the upgrade to the next 4.2.x
> series.
> This release contains fixes on the Maven repository management, the
> Feature gateway, the REST services (for both repository and deployer).
> 
> For complete details, please take a look on the release notes:
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342356
> 
> Git tag:
> cave-4.1.1
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1115/
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[VOTE] Apache Karaf Cave 4.1.1 release

2018-09-04 Thread Jean-Baptiste Onofré
Hi,

I submit Apache Karaf Cave 4.1.1 release to your vote.

This is a maintenance release on Cave 4.1.x series (working on Karaf
4.0.x, 4.1.x and 4.2.x), before starting the upgrade to the next 4.2.x
series.
This release contains fixes on the Maven repository management, the
Feature gateway, the REST services (for both repository and deployer).

For complete details, please take a look on the release notes:

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342356

Git tag:
cave-4.1.1

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1115/

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[HEADS UP] Weekly actions

2018-09-02 Thread Jean-Baptiste Onofré
Hi guys,

I just wanted to provide an update on the WIP for this week:

- related to the latest board report, I'm doing a cleanup of
dist.apache.org for Karaf. Basically, I'm removing all useless files
without signature like the *.pom files
- Today and tomorrow I will do a review on couple of CVE report. I will
provide a specific feedback about that.
- During the weekend, I started a refactoring of Cave. Cave 4.1.1 should
be in vote today or tomorrow.
- Maybe you saw the new tooling to create Karaf Docker image introduced
in 4.2.1:
  https://github.com/apache/karaf/tree/master/assemblies/docker
I will create a docker PR later today to automatically create a docker
Karaf official image for new release.
- In the mean time, I will also continue Decanter updates in preparation
for the release
- Related to our discussion during 4.2.1 release about a regular pace in
Karaf releases, I will prepare a release schedule that I will submit to you.
- I also started a blog post about Karaf 4.2.1 with specific focus on
Docker feature and support

Stay tuned !

Thanks !
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[REPORT] Apache Karaf

2018-08-31 Thread Jean-Baptiste Onofré
## Description:
 - Apache Karaf provides a very modern and polymorphic container,
multi-purpose (microservices, OSGi, etc) powered by OSGi.

## Issues:
 - There are no issues requiring board attention at this time

## Activity:
 - New update/polishing on the website
 - New important versions have been released (4.2.1)
 - A talk about Karaf will stand at ApacheCon NA
 - We are preparing new subprojects releases (Cave, Decanter) and a new
subproject (Vineyard)

## Health report:
 - We asked communities to share their experience/usage of Karaf to
populate the Stories pages on our website
 - We can see updates from users asking for release so we agreed to have
a periodically release cycle (every two months).
 - We note a growing interest for Karaf in the cloud and Karaf with docker.
 - We are reviewing a CVE report

## PMC changes:
 - Currently 15 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Christian Schneider on Mon Aug 22 2016

## Committer base changes:
 - Currently 31 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Francois Papon at Sat May 19 2018

## Releases:
 - 4.1.6 was released on Sun Aug 12 2018
 - 4.2.1 was released on Wed Aug 22 2018

## /dist/ errors: 15
 - We are updating the signature for the existing releases on  dist
(it's "old" releases on maintenance branches)

## Mailing list activity:

 - dev@karaf.apache.org:
- 187 subscribers (up 2 in the last 3 months):
- 173 emails sent to list (179 in previous quarter)

 - iss...@karaf.apache.org:
- 42 subscribers (up 0 in the last 3 months):
- 927 emails sent to list (904 in previous quarter)

 - u...@karaf.apache.org:
- 365 subscribers (up 1 in the last 3 months):
- 517 emails sent to list (416 in previous quarter)


## JIRA activity:

 - 110 JIRA tickets created in the last 3 months
 - 119 JIRA tickets closed/resolved in the last 3 months
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Board report for this month

2018-08-29 Thread Jean-Baptiste Onofré
Yeah, good point. I will also add note about CVE reviews in progress.

Regards
JB

Le 30 août 2018 à 06:50, à 06:50, "francois.papon" 
 a écrit:
>Hi,
>May be we could add the growing interest of the users about running
>Apache Karaf in the cloud ?
>regards,
>François 
>Envoyé depuis mon smartphone Samsung Galaxy.
> Message d'origine ----De : Jean-Baptiste Onofré
> Date : 30/08/2018  08:23  (GMT+04:00) À : Karaf Dev
> Objet : Board report for this month 
>Hi guys,
>
>our board report is due this month. I prepared the board report:
>
>https://cwiki.apache.org/confluence/display/KARAF/Board+Reports
>
>Please take a look and let me know if you want to update it.
>
>I plan to send the report later before the end of this week.
>
>Regards
>JB
>--
>Jean-Baptiste Onofré
>jbono...@apache.org
>http://blog.nanthrax.net
>Talend - http://www.talend.com


Board report for this month

2018-08-29 Thread Jean-Baptiste Onofré
Hi guys,

our board report is due this month. I prepared the board report:

https://cwiki.apache.org/confluence/display/KARAF/Board+Reports

Please take a look and let me know if you want to update it.

I plan to send the report later before the end of this week.

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[ANN] Apache Karaf 4.2.1 has been released !

2018-08-28 Thread Jean-Baptiste Onofré
The Apache Karaf team is pleased to announce Apache Karaf 4.2.1 release!

Apache Karaf 4.2.1 is a major update on the 4.2.x series. It brings
bunch of fixes, dependencies updates
and new features, especially:

* new assembly tooling to create Karaf Docker images
* new Docker feature allowing you to manipulate Docker directly from a
Karaf instance
* Better Java 9/10/11 support
* new examples directly as part of the Karaf distribution
* improved KarafTestSupport allowing you to easily implement your itests

You take a look on the Release Notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342945

You can download the release from the Karaf website:

http://karaf.apache.org/download.html#container-421

Enjoy !

The Karaf Team


JB's back

2018-08-27 Thread Jean-Baptiste Onofré
Hi guys,

Maybe you saw that I took some days off last week. I landed back last
night, so, just time to unstack my e-mails and I'm back ;)

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [PROPOSAL] - Stories page on website

2018-08-27 Thread Jean-Baptiste Onofré
Hi

We have a slack channel on the official ASF slack.

Regards
JB

Le 27 août 2018 à 18:18, à 18:18, "Łukasz Dywicki"  a 
écrit:
>> As we discuss on Slack,
>Did you mean IRC maybe? I haven't noticed that we have any Slack
>channel.
>
>
>> I pushed a PR about adding a stories page on the
>> website to talk about Karaf ecosystem :
>>
>> https://github.com/fpapon/karaf-site/tree/STORIES
>>
>> I made a proposal structure of the page and add some stories after
>> talking with JB.
>>
>> This is a WIP so you can complete or fix it you want :)
>
>I think it is very good idea to show real use cases of Karaf. There are
>many companies around which use Karaf and we implicitly know that but
>can not tell that explicitly. We either learned by finding posts from
>some companies and their employees on our mailing lists, direct contact
>with such people at various events or simply from job offers published
>around which mention (Apache) Karaf.
>
>It would be good if we could publish explicitly not only open source
>projects but - as you did - also commercial products based on Apache
>Karaf.
>For products I think we need some kind of agreement or confirmation to
>expose such information in public.
>
>I checked your site fork and I am not sure if WebSphere really uses
>Karaf. Other thing is that we need to respect trademark usage. Not sure
>if we can/should mention WebSphere alone or it as IBM WebSphere, but
>for
>that we most likely can ask legal@.
>Usually things are quite opposite - companies claim compatibility or
>support for enterprise version of Apache Software Foundation project
>such Datastax -> Apache Cassandra and so on.
>
>Cheers,
>Lukasz


Re: Karaf target audience and release granularity

2018-08-19 Thread Jean-Baptiste Onofré
I guess for async.

Regards
JB

On 19/08/2018 12:21, Francois Papon wrote:
> Hi,
> 
> I don't really understand why using JMS, can you explain ?
> 
> regards,
> 
> François Papon
> fpa...@apache.org
> 
> Le 19/08/2018 à 03:13, Castor a écrit :
>> "by the way, what do you mean about remote admin ? Is it something like 
>> the Deployer feature we have in Cave?"
>>
>> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
>> also created a suport to pre and post install hooks and plugins, blue-green
>> deployment, remote health checks and so on. 
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf target audience and release granularity

2018-08-19 Thread Jean-Baptiste Onofré
That sounds like Cave Deployer to me.

Regards
JB

On 19/08/2018 08:27, Christian Schneider wrote:
> Sounds interesting. Do you think you could write blog about your approach?
> 
> Christian
> 
> Am So., 19. Aug. 2018 um 01:42 Uhr schrieb Castor :
> 
>> "by the way, what do you mean about remote admin ? Is it something like
>> the Deployer feature we have in Cave?"
>>
>> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
>> also created a suport to pre and post install hooks and plugins, blue-green
>> deployment, remote health checks and so on.
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf target audience and release granularity

2018-08-18 Thread Jean-Baptiste Onofré
Catcha.

Don't hesitate to create a Jira to extend the Cave Deployer to use the
same features !

Regards
JB

On 19/08/2018 01:13, Castor wrote:
> "by the way, what do you mean about remote admin ? Is it something like 
> the Deployer feature we have in Cave?"
> 
> Yes! the deploy module is quite similar, but using JMS instead of JMX, i've
> also created a suport to pre and post install hooks and plugins, blue-green
> deployment, remote health checks and so on. 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [VOTE] Apache Karaf "Container" 4.2.1 release

2018-08-18 Thread Jean-Baptiste Onofré
+1 (binding)

Regards
JB

On 18/08/2018 15:34, Jean-Baptiste Onofré wrote:
> Hi,
> 
> I submit Apache Karaf 4.2.1 release to your vote.
> 
> This release is a major update on the 4.2.x series. It includes bunch of
> dependencies updates, fixes and new features, especially:
> 
> - Better Java 9/10/11 support
> - Assembly tooling to create Docker image, by the way, official Karaf
> images will be available soon using these scripts
> - Docker feature allowing you to manipulate Docker directly from Karaf
> - Improved itest KarafTestSuport to create your own itests easily
> - Updated dev guide with examples included in the Karaf standard
> distribution (and using in the itests)
> 
> For complete details, please take a look on the release notes:
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342945
> 
> Git tag:
> karaf-4.2.1
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1114/
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [VOTE] Apache Karaf "Container" 4.2.1 release

2018-08-18 Thread Jean-Baptiste Onofré
Thanks for the report Christian. I will create the corresponding Jira to
fix that for 4.2.2.

Regards
JB

On 18/08/2018 19:30, Christian Schneider wrote:
> +1
> 
> Found some issues on windows:
> When unpacking the zip on windows I get path too long for
> BookingServiceImpl.java.
> I think some of the examples are layered too deeply.
> 
> Another issue on windows is with the shell. If I do feature:install 
> then a long list of features appears. If I scroll thorugh the results using
> tab the screen soon becomes totally garbled.
> 
> So nothing very big but some things for 4.2.2 I guess.
> 
> Christian
> 
> Am Sa., 18. Aug. 2018 um 15:34 Uhr schrieb Jean-Baptiste Onofré <
> j...@nanthrax.net>:
> 
>> Hi,
>>
>> I submit Apache Karaf 4.2.1 release to your vote.
>>
>> This release is a major update on the 4.2.x series. It includes bunch of
>> dependencies updates, fixes and new features, especially:
>>
>> - Better Java 9/10/11 support
>> - Assembly tooling to create Docker image, by the way, official Karaf
>> images will be available soon using these scripts
>> - Docker feature allowing you to manipulate Docker directly from Karaf
>> - Improved itest KarafTestSuport to create your own itests easily
>> - Updated dev guide with examples included in the Karaf standard
>> distribution (and using in the itests)
>>
>> For complete details, please take a look on the release notes:
>>
>> Release Notes:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342945
>>
>> Git tag:
>> karaf-4.2.1
>>
>> Staging Repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-1114/
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Don't approve the release (please provide specific comments)
>>
>> This vote will be open for at least 72 hours.
>>
>> Thanks,
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf target audience and release granularity

2018-08-18 Thread Jean-Baptiste Onofré
I disagree here. We can have different perspective.

We have some users that use Karaf on Docker for infra, and use Cellar
with Kubernetes for node discovery. That's an approach.

Another option is to use the Karaf static profile (we have an example
now in the distribution) or a custom distribution (thanks for the
assembly/docker scripts we now have in the distribution).

As reminder, this is a Karaf related mailing list.

Regards
JB

On 18/08/2018 19:24, Christian Schneider wrote:
> For cloud deployments you normally want to implement the immutable server
> pattern:
> https://martinfowler.com/bliki/ImmutableServer.html
> 
> This means that your whole deployment including config should be defined
> from e.g. a github repository.
> You do not want to have upgrades of bundles or config during the lifetime
> of a pod. Of course your still want to have this for development.
> So you need some assembly process but it completely happens at build time
> of the docker image.
> You then want to feed some instance specific config using env variables.
> 
> So translated to karaf the ideal deployment is to resolve the features at
> build time and only deploy a list of bundles.
> This can already be done using the static profile of karaf.
> Overriding the config using env variables is possible using the new felix
> configurator. It is not yet added to karaf but should be no bigger issue.
> So basically you create a custom distro with static profile, your features
> and the configurator. Then you create a docker image from it.
> The result should then behave quite nicely in kubernetes.
> 
> I would not use the karaf clustering features (cellar). As you deploy
> static docker images the cellar features do not help much.
> So in summary karaf can be nicely tailored for kubernetes. I think though
> that you can go even smaller without karaf if you want to go for kubernetes.
> 
> I am currently epxerimenting with the new OSGi R7 features that allow to do
> an assembly based on annotations. So for example the new http whiteboard
> annotations
> have a dual purpose. They tell the http service to install a service as a
> servlet but they also add a requirement for a whiteboard extender.
> These annotations allow to do a deployment without specifiying features. If
> you use them well you can simply tell the resolver to deploy your bundle,
> give it a repository of
> bundles and it automatically selects a good set of bundles.
> I am currently doing this with a bndrun file using the bnd maven plugins.
> The result of the build is then a runnable jar that looks like what spring
> boot produces.
> It is quite easy to create a docker image from this and run it in
> kubernetes.
> See this example https://github.com/cschneider/osgi-example-systemready.
> 
> I am pretty sure we can use the new R7 annotations to also make karaf
> deployments simpler.
> 
> I will do a talk about systemready and kubernetes at adaptto 2018.
> For javaland 2019 I proposed a talk about Cloud native OSGi. The idea is to
> check how well OSGi already fits into the cloud and what we need to make it
> fully cloud native.
> 
> Christian
> 
> .Am Sa., 18. Aug. 2018 um 18:08 Uhr schrieb Matt Sicker :
> 
>>
>> I'm not sure how much you've used Kubernetes, but I wonder how well Karaf
>> Boot could work in that sphere. I still believe strongly in modularity and
>> the ecosystem around it, and if Karaf makes it easier to "migrate to the
>> cloud" so to say (and not just in a superficial matter; modularity should
>> help enforce boundaries that are explicitly needed in distributed systems),
>> then that could be a killer feature. The existing work with clustering
>> looks extremely relevant to this, though I'm not familiar with how that
>> interacts with k8s.
>>
>> On Fri, 17 Aug 2018 at 23:09, Jean-Baptiste Onofré 
>> wrote:
>>
>>> Hi,
>>>
>>> by the way, what do you mean about remote admin ? Is it something like
>>> the Deployer feature we have in Cave ?
>>>
>>> By the way, I will take some days off next week, but after I will send a
>>> proposal on the mailing list with:
>>>
>>> 1. Release agenda
>>> 2. Karaf Container roadmap
>>> 3. Karaf Vineyard
>>>
>>> Stay tuned !
>>>
>>> Regards
>>> JB
>>>
>>> On 17/08/2018 22:12, Castor wrote:
>>>> Ohh yeah, at the beginning the mechanism was quite confusing, it still
>>> give
>>>> me some headaches sometimes, like a feature with no dependencies with a
>>>> bundle importing only a servlet triggering a refresh of the whole
>>> platform.
>>>>
>>>

[VOTE] Apache Karaf "Container" 4.2.1 release

2018-08-18 Thread Jean-Baptiste Onofré
Hi,

I submit Apache Karaf 4.2.1 release to your vote.

This release is a major update on the 4.2.x series. It includes bunch of
dependencies updates, fixes and new features, especially:

- Better Java 9/10/11 support
- Assembly tooling to create Docker image, by the way, official Karaf
images will be available soon using these scripts
- Docker feature allowing you to manipulate Docker directly from Karaf
- Improved itest KarafTestSuport to create your own itests easily
- Updated dev guide with examples included in the Karaf standard
distribution (and using in the itests)

For complete details, please take a look on the release notes:

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342945

Git tag:
karaf-4.2.1

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1114/

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf target audience and release granularity

2018-08-17 Thread Jean-Baptiste Onofré
Hi,

by the way, what do you mean about remote admin ? Is it something like
the Deployer feature we have in Cave ?

By the way, I will take some days off next week, but after I will send a
proposal on the mailing list with:

1. Release agenda
2. Karaf Container roadmap
3. Karaf Vineyard

Stay tuned !

Regards
JB

On 17/08/2018 22:12, Castor wrote:
> Ohh yeah, at the beginning the mechanism was quite confusing, it still give
> me some headaches sometimes, like a feature with no dependencies with a
> bundle importing only a servlet triggering a refresh of the whole platform.  
> 
> "For the update, I don't know which karaf version you are using, but
> Karaf 4.2.x has some improvements with feature:update."
> 
> We are using karaf 4.1.5 right now, we will wait for Karaf 4.2.1 to start
> some testing. 
> 
> 
> "Feel free to create Jira corresponding
> to your ideas, and feel free to contribute. Any help is welcome !"
> 
> Will do, i plan to release an open-source version of our remote admin for
> karaf which i am working on my free time, should take a couple months. 
> 
> Thanks!
> 
> 
> 
> 
> jbonofre wrote
>> Hi,
>>
>> Thanks for sharing your experience.
>>
>> I don't say that it's your case, but most of the time, when people
>> complains about refresh, it's because they don't know/understand the
>> underlying mechanisms.
>> Basically, I had the case with a customer that used a bunch of optional
>> import and complain of the refresh: the issue was basically a design
>> error and an mistake in the bundles.
>>
>> For the update, I don't know which karaf version you are using, but
>> Karaf 4.2.x has some improvements with feature:update.
>>
>> About spring-boot like, it's part of the karaf-boot scope.
>>
>> Anyway guys, I think you have very good ideas and it's really great you
>> share your experience/use cases. Feel free to create Jira corresponding
>> to your ideas, and feel free to contribute. Any help is welcome !
>>
>> Thanks
>> Regards
>> JB
>>
>> On 17/08/2018 21:34, Castor wrote:
>>> I can tell a little about my experience with karaf. 
>>>
>>> Here we have an ERP writen in delphi (that was written in natural before
>>> that) which we need to "upgrade" to a cloud capable software, using the
>>> same
>>> database and mantaining the old software while we rewrite negotial rules
>>> in
>>> java. Great part of our clients are small-medium with on-premises, so we
>>> had
>>> to maintain a architecture easy enough for on-premises and able to use a
>>> cloud structure with clusters and so on. 
>>>
>>> So, we are using karaf for that, OSGi services lets us to build
>>> "microservices" and have a easier reuse of Negotial Rules, with common
>>> transactions and so on (icks for XA .  
>>>
>>> Well, it works, but we have some headaches, we had to build or own
>>> dependency mechanism, because every single feature refreshed the hell of
>>> karaf, we also built an remote admin to update services on-the-fly in
>>> every
>>> single customer, it's working quite nicely, we still have some trouble
>>> with
>>> failed bundles, but nothing irremediable. 
>>>
>>> Two things that would help us a lot, a spring-boot like app and an easier
>>> way to update karaf version, for the updates we had to create a updater
>>> which saves a list of negotial bundles, reinstall karaf and restores the
>>> bundles, it works but it's quite meh. 
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>>
>>
>> -- 
>> Jean-Baptiste Onofré
> 
>> jbonofre@
> 
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
> 
> 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf target audience and release granularity

2018-08-17 Thread Jean-Baptiste Onofré
Hi,

Thanks for sharing your experience.

I don't say that it's your case, but most of the time, when people
complains about refresh, it's because they don't know/understand the
underlying mechanisms.
Basically, I had the case with a customer that used a bunch of optional
import and complain of the refresh: the issue was basically a design
error and an mistake in the bundles.

For the update, I don't know which karaf version you are using, but
Karaf 4.2.x has some improvements with feature:update.

About spring-boot like, it's part of the karaf-boot scope.

Anyway guys, I think you have very good ideas and it's really great you
share your experience/use cases. Feel free to create Jira corresponding
to your ideas, and feel free to contribute. Any help is welcome !

Thanks
Regards
JB

On 17/08/2018 21:34, Castor wrote:
> I can tell a little about my experience with karaf. 
> 
> Here we have an ERP writen in delphi (that was written in natural before
> that) which we need to "upgrade" to a cloud capable software, using the same
> database and mantaining the old software while we rewrite negotial rules in
> java. Great part of our clients are small-medium with on-premises, so we had
> to maintain a architecture easy enough for on-premises and able to use a
> cloud structure with clusters and so on. 
> 
> So, we are using karaf for that, OSGi services lets us to build
> "microservices" and have a easier reuse of Negotial Rules, with common
> transactions and so on (icks for XA .  
> 
> Well, it works, but we have some headaches, we had to build or own
> dependency mechanism, because every single feature refreshed the hell of
> karaf, we also built an remote admin to update services on-the-fly in every
> single customer, it's working quite nicely, we still have some trouble with
> failed bundles, but nothing irremediable. 
> 
> Two things that would help us a lot, a spring-boot like app and an easier
> way to update karaf version, for the updates we had to create a updater
> which saves a list of negotial bundles, reinstall karaf and restores the
> bundles, it works but it's quite meh. 
> 
> 
> 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf target audience and release granularity

2018-08-17 Thread Jean-Baptiste Onofré
Hi Robert,

thanks for your feedback, and I fully agree with you.

For the release, it's largely my fault for 4.2.1: I wanted to include
too much fixes, upgrades and new features. My bad, and apologize for
that. That's why I wanted to propose to reduce scope of the releases and
do it on a regular pace, much more predictable to users/devs like you.

For the changes, we are now much more "strict" in the changes we are
doing. Any breaking changes is not allowed on a minor release.

For the documentation, we started a huge work on this one. You can
already see the user guide is largely better than before IMHO. Now the
target is on the dev guide and related examples.

I see your point the way you are "packaging" the features. Any reason
why you don't manage your features repository by hand ?

Anyway, 4.1.6 has been released and 4.2.1 will be on vote tonight.
Starting for there, I will send the release agenda with a release every
two months for both Karaf Container but also the subprojects.

Thanks !
Regards
JB

On 17/08/2018 15:12, Robert Varga wrote:
> Hello Jamie, everyone,
> 
> On 16/08/18 10:46, Jamie G. wrote:
>> Karaf is used / consumed heavily in the SDN world (see OpenDaylight &
>> its ecosystem).
>>
>> For that community they do treat Karaf as a SDK for developing their
>> apps, its also of course their runtime.
>>
>> The long support runs we provide for Karaf major versions is seen as a
>> benefit as SDN deployments typically run major infrastructure. The
>> release pace is a function of available time from the community -
>> speaking from my experiences with Karaf releases they are a fare
>> amount of work; more hands involved in testing, stabilizing builds,
>> etc are always welcomed :)
>>
>> As to how Karaf is presented; Karaf is many things to many people, I'd
>> rather keep the open development possibilities than restrict them.
> 
> As one of the guys who spent countless hours pushing Karaf upgrades
> through the OpenDaylight ecosystem and with m OpenDaylight Offset-0 TSC
> Representative hat on, I would like to contribute the follow to the
> discussion:
> 
> I whole-heartily support faster and more predictable release schedule.
> OpenDaylight follows strict 6 month release cadence
> (https://opendaylight.readthedocs.io/en/latest/release-process/release-schedule.html).
> Third-party component upgrades are integrated in the first 6 weeks, with
> only very minor adjustments being done afterwards. In this context
> karaf-4.2.1 and karaf-4.1.6 having slipped as much as they did is very
> bad for ability to plan ahead.
> 
> Furthermore, so far each and every Karaf upgrade has been problematic --
> partly because of the technical debt present in our code base, but more
> importantly due to sheer amount of changes even a x.x.1 bump in Karaf
> version brings to the table. Those changes have been quite uncontrolled
> in the past -- like the change in the default TransformerFactory in
> 3.0.6, which caused quite a lot of grief evidenced in
> https://bugs.opendaylight.org/show_bug.cgi?id=5917.
> 
> While we have reasons for using Karaf in OpenDaylight, it is seen by
> many developers as an unneeded complication of our platform -- to the
> point that there is https://lighty.io and
> https://wiki.opendaylight.org/view/Events:Neon_Dev_Forum#OpenDaylight_without_Karaf_and_OSGi.
> 
> As far as I understand the motivations, there are three drivers:
> - regard of OSGi as an unnecessary complication
> - the kitchen-sink nature of Karaf packaging, which brings unneeded fat,
> especially considering the general move to stateless containers
> - slow and painful upgrade process
> 
> Aside from the schedule, I would like to make two technical asks:
> 
> 1) Thoroughly document features specification
> 
> We use features as a deployment descriptor to tie together the
> components of our system, with the OpenDaylight distribution contains
> around 300 individual features. While features are cool, they also seem
> to be quite under-documented, especially in terms of their interplay
> with the resolver -- for example, what exactly does it exactly mean to
> declare a feature dependency with dependency=true and prerequisite=true
> from perspective of feature/bundle lifecycle?
> 
> 2) Split up feature repositories into individual features
> 
> OpenDaylight is structured as a set of individual projects, which
> gradually build up the platform. We use extensively karaf-maven-plugin
> to generate features and the fact that individual features in
> features/standard are not available as maven artifacts forces us to
> define things like
> https://github.com/opendaylight/odlparent/tree/master/features/odl-karaf-feat-jetty
> just to get sane features generated without pulling in all of standard.
> 
> Thanks,
> Robert
> 


Re: Karaf target audience and release granularity

2018-08-16 Thread Jean-Baptiste Onofré
Hi Toni,

That's an aspect of Karaf that we should improve, and that's exactly the
purpose of:

1. The examples coming in the 4.2.1 (as part of the standard
distribution): https://github.com/jbonofre/karaf/tree/DEV_GUIDE

2. karaf-boot.

I started karaf-boot exactly to facilitate the view of Karaf for developers.

Even if the focus is users first, we should extend to have a "Karaf
developer friendly", even simplifying some OSGi parts for non OSGi
people. It means that Karaf Boot will do choices: it will engage
developers on some well defined patterns. Of course, there will be lot
of different alternatives, but karaf-boot will follow one.
The karaf-boot tagline is "just do your business code, karaf-boot deals
with the rest". So basically, you will add some karaf-boot annotations
in your code, and karaf-boot will create the artifacts, even the Karaf
distribution, for you.

However, I still think that our highest priority audience is
users/devops, and the second audience is devs.

François and I are working on Karaf Vineyard (API Registry/Gateway),
focused really on service platform for users/devops.

I would love to have some feedback and helps on karaf-boot (the repo is
on my github).

Thanks Toni !

Regards
JB

On 16/08/2018 12:14, Toni Menzel wrote:
> Thanks everyone for your quick replies.
> 
> I see your point, JB. "One of the key part of Karaf is use friendly." thats
> what i mean by "opinionated felix distro".
> It may sound as a bad thing but i mean it as a feature: it puts "batteries"
> included onto the osgi fw, has opinions how to configure stuff and where
> logs go and how to do things you normally would expect from a complete
> solution.
> I would expect use-friendliness should be a feature of every product. Who
> wants software that is hostile at you ? ;)
> 
> About "Product Project" well ok then. Thats the "Product Karaf" direction.
> Good one!
> 
> Though, there might be room for improvements in the area "Karaf for SDK
> Vendors"?
> Treat the following as insight into how we use Karaf "not" as a product but
> as the fabric for (business-) developers.
> Our customers are building developer experiences (e.g. APIs for specific
> problem domains) on top of Karaf Minimal.
> 
>1. We take Karaf Minimal and create custom distributions with all
>technical features embedded, preconfigured & tested.This often includes a
>lot of messy "OSGi-fied" legacy projects too.
>2. We add business-centric/domain APIs to that distro. This is the
>user-facing programming model. The only thing that leaks technically is the
>fact that usually the model is being accessed as OSGi Services using DS.
>But this is even exchangeable.We call the user-facing api "baseline api".
>3. They get all this as an "SDK" which is made of a Docker Image,
>Zip-Assembly and as an on-demand/per-user cloud service (all runtimes) and
>Baseline-APIs artifacts (compile target).
>4. They program against the baseline-api producing deliverables (usually
>OSGi Bundles but could be anything accepted by the runtime).
>5. Delivery is very customer specific, ranging from pre-baking "all
>included" docker images or an app-store-like SaaS Model.
> 
> So we treat Karaf (and with it OSGi) as the internal fabric that is
> technically exposed to the user (OSGi bundles, DS API, Diagnostics via
> Karaf Shell etc.) but semantically not at all relevant (that is what the
> baseline api is for).
> 
> Its works very well but its nowhere as convenient as it could be.
> Let me mention a few - knowing that we also work on some of them internally:
> 
>- Limiting customisation to Maven is one thing (yeah.. everyone has its
>build ecosystem)
>- Karaf Boot seemed like a good start. But its went nowhere i think? [1]
>- Customizers don't care about pre-attached (opinionated) spring or
>enterprise repos that come (and change) with releases.
>- Branding seems like a niche thing. Yes there are knobs everywhere
>(webconsole, shell) but it could be addressed on a more systematic thing.
>Do other people care?
> 
> Maybe this helps seeing Karaf not only as a product.
> 
> 
> [1] https://github.com/apache/karaf-boot
> 
> 
> 
> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
> 
> On Thu, Aug 16, 2018 at 10:48 AM, Jean-Baptiste Onofré 
> wrote:
> 
>> Hi Toni,
>>
>> I know a fairly large set of users that use Karaf without knowing OSGi.
>>
>> That's why it's a polymorphic container: some use spring, some use OSGi,
>> some use blueprint, s

Re: Two more interesting bumps for Karaf 4.2.1

2018-08-16 Thread Jean-Baptiste Onofré
Hi,

It's already on the way:

https://issues.apache.org/jira/browse/KARAF-5870
https://github.com/apache/karaf/pull/594

Regards
JB

On 16/08/2018 11:47, Mikael Åsberg wrote:
> Thanks for doing those updates! Is it too late to take in the latest
> version of hibernate validator before the vote? Thanks for all the great
> work!
> 
> On Sun, Aug 12, 2018, 16:07 Jean-Baptiste Onofré  wrote:
> 
>> Hi,
>>
>> I'm on the updates and yes, the vote is almost there as I'm fixing the
>> last itests on examples.
>>
>> Thanks !
>> Regards
>> JB
>>
>> On 12/08/2018 15:00, Eric Lilja wrote:
>>>
>>> These include: EclipseLink 2.7.3 and org.apache.felix.scr 2.1.2
>>>
>>> Any possibility they could be included? I suspect the vote is imminent
>>> since I noticed the Pax Web upgrade was just resolved.
>>>
>>> - EL
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[PROPOSAL] Using Jenkins for Karaf test on Windows platform

2018-08-16 Thread Jean-Baptiste Onofré
Hi all,

regarding issues we had (and still have) on Windows platform (especially
with the shell), I would like to create a job on Jenkins dedicated to
execute the itest on Windows (and add some related shell itests).

No objection ?

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Karaf target audience and release granularity

2018-08-16 Thread Jean-Baptiste Onofré
Hi Toni,

I know a fairly large set of users that use Karaf without knowing OSGi.

That's why it's a polymorphic container: some use spring, some use OSGi,
some use blueprint, some use directly war, etc. There are several facet
of using Karaf.

About the distribution, to be honest, I only know users of standard
distribution: either directly Karaf vanilla and then installing features
and their applications, or creating their own custom distribution
starting from the standard one. They don't necessary use the enterprise
features, it's more the standard distribution + their own features.

One of the key part of Karaf is use friendly. That's the difference
starting from the framework. When you start from felix framework, it's
up to you to construct all: logging management, hot deployment, ...
Starting from Karaf it's a turnkey solution, having all user facing aspects.
Karaf container and all its subprojects are really focused on user.

Look at Decanter: it's tremendous simple solution but it does the job
and users just use it.

Karaf is a "product project", it's not a SDK. It's a multi-purpose
runtime, powered by OSGi, but OSGi is not necessary the user facing model.

That's why, as a "product project", I think it makes sense to have
regular release pace.

Regards
JB

On 16/08/2018 10:09, Toni Menzel wrote:
> As mentioned, here are some more thoughts on Karaf audience/usage.
> 
> Do you know how Karaf users consume/use Karaf? This is important to get a
> good release cycle and granularity. (as teased by JB on this list recently).
> 
> Why i am mentioning that? Well,i always felt that Karaf (the container) is
> a rather large thing with all its feature repos coming with it. I think
> thats why Karaf releases where coming rather slow in the past. (correct or
> not?)
> 
> *1. Karaf as an opinionated felix distro*
> 
> This "batteries" included feature is (was?) a core selling point of Karaf
> but is this really how people use it?
> I know at least two larger customers who are baking their own Karaf
> distribution anyway based on the minimal profile.
> 
> So i am asking, wouldn't it make sense to release the "base" runtime (say
> Felix+Karaf infrastructure like pax-url, feature system, configuration
> system) independently? Similar to what you get with Karaf minimal.
> 
> Depending on how Karaf is used in the real world (do you know?), here are
> some radical thoughts on my/our personal usage:
> 
>- Karaf Minimal becomes "Karaf Runtime" because its base unit you can
>put everything on top (even at runtime).
>- Karaf Standard/Enterprise becomes the "Karaf SDK" since has the
>kitchen-sink nature that is great when you want to tinker with
>Spring,Hibernate etc.
> 
> Also, wouldn't it make sense to release the maven-plugin independently?
> 
> Those changes might seem of no importance to Karaf insiders (because you
> get all of that already when building your own distro) but at least I only
> found Karaf reasonable for a lot of usecases until i found out how to
> really only get the "runtime" part. Now i can say that for me Karaf is an
> opinionated felix  distro (yes.. not only that but you get the point).
> 
> *2. Karaf as polymorphic container*
> 
> On the website Karaf is marketed as "Karaf can host any kind of
> applications: OSGi, Spring, WAR, and much more". Is that how people really
> use it? I mean.. are Spring (Boot..) people happy living inside Karaf?
> Every OSGi-savvy person recommends going DS, staying with OSGi spec
> standards and avoid War. - pun intended.
> Yeah, its great for demos but is it worth the effort? - also to keep this
> "working". And - from experience - i can tell that its also not a
> recommendable migration path. It sounds great but Hibernate and friends are
> actually quite hostile to your OSGi framework instance introducing a lot
> more complexity into your system. And if even OSGi-savvy people have
> problems troubleshooting such cases, how should a team of beginners do that?
> 
> *3. Karaf as a better solution for Microservices*
> 
> Guess i save this for another post, too easy to turn this into a rant. Let
> me just say: i think Karaf is one of the few answers to the pervasive
> Microservice/Spring Boot ecosystem. But it is not obvious and people stay
> away from it because. Again, this COULD go very long, but it is not the
> right place.
> 
> Any thoughts?
> 
> * What is Developer Ergonomics <https://medium.com/rebaze>**? *
> 
> 
> 
> *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com
> <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>*
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


4.2.1 vote tonight/tomorrow morning | Karaf regular release pace

2018-08-15 Thread Jean-Baptiste Onofré
Hi guys,

as I don't want to hold 4.2.1 any longer, I will merge the last PRs
today and I will submit 4.2.1 to vote tonight/tomorrow early morning.

If required I will cut a 4.2.2 pretty soon.

I would like to propose a regular pace in our release, something like at
least (it's a minimum) a release every 2 month "as it is".

It would be easier for our user to get the changes "on the fly".

I would like to apply this for Karaf "container" but also for the
subprojects (Decanter, Cellar, Cave, ...).

Thoughts ?

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: 4.2.1-SNAPSHOT: stack overflow with commands

2018-08-15 Thread Jean-Baptiste Onofré
Hi Stephen,

Just to let you know that I'm not able to reproduce the issue on my VM.
I'm trying different setup, but I will probably postpone to 4.2.2 as I
don't want to hold 4.2.1 any longer.

Regards
JB

On 14/08/2018 10:19, Jean-Baptiste Onofré wrote:
> Hi
> 
> Thanks for the report. I will fix that. Windows just sucks ;)
> 
> Regards
> JB
> 
> Le 14 août 2018 à 10:16, à 10:16, "Siano, Stephan"  a 
> écrit:
>> Hi,
>>
>> I just wanted to try out the current 4.2.1-SNAPSHOT version of Karaf
>> (as it is supposed to be released soon). Therefore I built the master
>> branch locally and tried to start karaf with it (Windows 10, Sun JDK
>> 8).
>>
>> When I do a "su" on the console and then try to issue a command, I get
>> a StackOverflowError (see below). Is this a known issue?
>>
>> Best regards
>> Stephan
>>
>>__ __  
>>   / //_/ __ _/ __/
>>  / ,<  / __ `/ ___/ __ `/ /_
>> / /| |/ /_/ / /  / /_/ / __/
>>/_/ |_|\__,_/_/   \__,_/_/
>>
>>  Apache Karaf (4.2.1-SNAPSHOT)
>>
>> Hit '' for a list of available commands
>> and '[cmd] --help' for help on a specific command.
>> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>>
>> karaf@root()> su
>> Password: *
>>__ __  
>>   / //_/ __ _/ __/
>>  / ,<  / __ `/ ___/ __ `/ /_
>> / /| |/ /_/ / /  / /_/ / __/
>>/_/ |_|\__,_/_/   \__,_/_/
>>
>>  Apache Karaf (4.2.1-SNAPSHOT)
>>
>> Hit '' for a list of available commands
>> and '[cmd] --help' for help on a specific command.
>> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>>
>> karaf@root()> bundle:list -t 0 -s
>> Error executing command: java.lang.StackOverflowError
>> karaf@root()>
>>
>>
>> 2018-08-14T10:08:29,766 | WARN  | pipe-su  | jline 
>> | 42 - org.jline.terminal - 3.9.0 | The Parser of class
>> org.apache.karaf.shell.impl.console.ConsoleSessionImpl$$Lambda$377/363155922
>> does not support the CompletingParsedLine interface. Completion with
>> escaped or quoted words won't work correctly.
>> 2018-08-14T10:08:39,290 | ERROR | Karaf local console user karaf |
>> ShellUtil| 35 - org.apache.karaf.shell.core -
>> 4.2.1.SNAPSHOT | Exception caught while executing command
>> java.util.concurrent.ExecutionException: java.lang.StackOverflowError
>>  at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]
>> at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:?]
>> at
>> org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.run(CommandSessionImpl.java:851)
>> ~[?:?]
>> at
>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>> ~[?:?]
>> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>> ~[?:?]
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>> ~[?:?]
>> at java.lang.Thread.run(Thread.java:745) [?:?]
>> Caused by: java.lang.StackOverflowError
>> at
>> org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.getCurrent(ThreadPrintStream.java:41)
>> ~[?:?]
>> at
>> org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.write(ThreadPrintStream.java:89)
>> ~[?:?]
>> at
>> java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458)
>> ~[?:?]
>> at
>> org.apache.felix.gogo.runtime.Closure$WritableByteChannelImpl.write(Closure.java:326)
>> ~[?:?]
>> at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:643)
>> ~[?:?]
>>  at java.nio.channels.Channels.writeFullyImpl(Channels.java:78) ~[?:?]
>> at java.nio.channels.Channels.writeFully(Channels.java:101) ~[?:?]
>> at java.nio.channels.Channels.access$000(Channels.java:61) ~[?:?]
>> at java.nio.channels.Channels$1.write(Channels.java:174) ~[?:?]
>> at java.io.PrintStream.write(PrintStream.java:480) ~[?:?]
>> at
>> org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.write(ThreadPrintStream.java:89)
>> ~[?:?]
>> at
>> java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458)
>> ~[?:?]
>> at
>> org.apache.felix.gogo.runtime.Closure$WritableByteChannelImpl.write(Closure.java:326)
>> ~[?:?]
>> at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:643)
>>

Re: 4.2.1-SNAPSHOT: stack overflow with commands

2018-08-14 Thread Jean-Baptiste Onofré
Hi

Thanks for the report. I will fix that. Windows just sucks ;)

Regards
JB

Le 14 août 2018 à 10:16, à 10:16, "Siano, Stephan"  a 
écrit:
>Hi,
>
>I just wanted to try out the current 4.2.1-SNAPSHOT version of Karaf
>(as it is supposed to be released soon). Therefore I built the master
>branch locally and tried to start karaf with it (Windows 10, Sun JDK
>8).
>
>When I do a "su" on the console and then try to issue a command, I get
>a StackOverflowError (see below). Is this a known issue?
>
>Best regards
>Stephan
>
>__ __  
>   / //_/ __ _/ __/
>  / ,<  / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / /  / /_/ / __/
>/_/ |_|\__,_/_/   \__,_/_/
>
>  Apache Karaf (4.2.1-SNAPSHOT)
>
>Hit '' for a list of available commands
>and '[cmd] --help' for help on a specific command.
>Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>
>karaf@root()> su
>Password: *
>__ __  
>   / //_/ __ _/ __/
>  / ,<  / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / /  / /_/ / __/
>/_/ |_|\__,_/_/   \__,_/_/
>
>  Apache Karaf (4.2.1-SNAPSHOT)
>
>Hit '' for a list of available commands
>and '[cmd] --help' for help on a specific command.
>Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>
>karaf@root()> bundle:list -t 0 -s
>Error executing command: java.lang.StackOverflowError
>karaf@root()>
>
>
>2018-08-14T10:08:29,766 | WARN  | pipe-su  | jline
>| 42 - org.jline.terminal - 3.9.0 | The Parser of class
>org.apache.karaf.shell.impl.console.ConsoleSessionImpl$$Lambda$377/363155922
>does not support the CompletingParsedLine interface. Completion with
>escaped or quoted words won't work correctly.
>2018-08-14T10:08:39,290 | ERROR | Karaf local console user karaf |
>ShellUtil| 35 - org.apache.karaf.shell.core -
>4.2.1.SNAPSHOT | Exception caught while executing command
>java.util.concurrent.ExecutionException: java.lang.StackOverflowError
>  at java.util.concurrent.FutureTask.report(FutureTask.java:122) ~[?:?]
> at java.util.concurrent.FutureTask.get(FutureTask.java:192) ~[?:?]
>at
>org.apache.felix.gogo.runtime.CommandSessionImpl$JobImpl.run(CommandSessionImpl.java:851)
>~[?:?]
>at
>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:?]
>at
>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>~[?:?]
>at
>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>~[?:?]
> at java.lang.Thread.run(Thread.java:745) [?:?]
>Caused by: java.lang.StackOverflowError
>at
>org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.getCurrent(ThreadPrintStream.java:41)
>~[?:?]
>at
>org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.write(ThreadPrintStream.java:89)
>~[?:?]
>at
>java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458)
>~[?:?]
>at
>org.apache.felix.gogo.runtime.Closure$WritableByteChannelImpl.write(Closure.java:326)
>~[?:?]
>at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:643)
>~[?:?]
>  at java.nio.channels.Channels.writeFullyImpl(Channels.java:78) ~[?:?]
> at java.nio.channels.Channels.writeFully(Channels.java:101) ~[?:?]
> at java.nio.channels.Channels.access$000(Channels.java:61) ~[?:?]
> at java.nio.channels.Channels$1.write(Channels.java:174) ~[?:?]
> at java.io.PrintStream.write(PrintStream.java:480) ~[?:?]
>at
>org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.write(ThreadPrintStream.java:89)
>~[?:?]
>at
>java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458)
>~[?:?]
>at
>org.apache.felix.gogo.runtime.Closure$WritableByteChannelImpl.write(Closure.java:326)
>~[?:?]
>at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:643)
>~[?:?]
>  at java.nio.channels.Channels.writeFullyImpl(Channels.java:78) ~[?:?]
> at java.nio.channels.Channels.writeFully(Channels.java:101) ~[?:?]
> at java.nio.channels.Channels.access$000(Channels.java:61) ~[?:?]
> at java.nio.channels.Channels$1.write(Channels.java:174) ~[?:?]
> at java.io.PrintStream.write(PrintStream.java:480) ~[?:?]
>at
>org.apache.felix.gogo.runtime.threadio.ThreadPrintStream.write(ThreadPrintStream.java:89)
>~[?:?]
>at
>java.nio.channels.Channels$WritableByteChannelImpl.write(Channels.java:458)
>~[?:?]
>at
>org.apache.felix.gogo.runtime.Closure$WritableByteChannelImpl.write(Closure.java:326)
>~[?:?]
>at org.apache.felix.gogo.runtime.Pipe$MultiChannel.write(Pipe.java:643)
>~[?:?]
>  at java.nio.channels.Channels.writeFullyImpl(Channels.java:78) ~[?:?]
> at java.nio.channels.Channels.writeFully(Channels.java:101) ~[?:?]
> at java.nio.channels.Channels.access$000(Channels.java:61) ~[?:?]
> at java.nio.channels.Channels$1.write(Channels.java:174) ~[?:?]
> at java.io.PrintStream.write(PrintStream.java:480) ~[?:?]
>at

Re: Karaf on OSv

2018-08-13 Thread Jean-Baptiste Onofré
Hi,

I didn't get any feedback about Karaf running on OSv. Unfortunately I
don't have the required hardware to do some tests/PoC.
I would be more than happy to try, provide help or gather feedback.

Regards
JB

On 13/08/2018 19:22, Ranx wrote:
> Interesting. There aren't any thoughts, insights, rants, or wonky input?
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 


Re: [IRC] - spam

2018-08-13 Thread Jean-Baptiste Onofré
Hi,

It seems it becomes worst on IRC. I didn't have any update from freenode.

In order for me to become op again, can you please guys leave IRC
channel for a while ?

I will keep you posted when spam is fixed.

Thanks,
Regards
JB

On 08/08/2018 12:53, Francois Papon wrote:
> Hi,
> 
> We have a lot of spam on the IRC channel, is there a way to hide them in
> the channel admin ?
> 
> regards,
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[ANN] Apache Karaf 4.1.6 released !

2018-08-12 Thread Jean-Baptiste Onofré
The Apache Karaf team is pleased to announce Apache Karaf 4.1.6 release!

This is a maintenance release on the 4.1.x series, bringing fixes and
dependency updates.

You take a look on the Release Notes for details:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748

You can download the release from the Karaf website:

http://karaf.apache.org/download.html

Enjoy !

The Karaf Team


Re: Two more interesting bumps for Karaf 4.2.1

2018-08-12 Thread Jean-Baptiste Onofré
Hi,

I'm on the updates and yes, the vote is almost there as I'm fixing the
last itests on examples.

Thanks !
Regards
JB

On 12/08/2018 15:00, Eric Lilja wrote:
> 
> These include: EclipseLink 2.7.3 and org.apache.felix.scr 2.1.2
> 
> Any possibility they could be included? I suspect the vote is imminent
> since I noticed the Pax Web upgrade was just resolved.
> 
> - EL
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[RESULT][VOTE] Apache Karaf (Container) 4.1.6 release - take #2

2018-08-11 Thread Jean-Baptiste Onofré
Hi,

This vote passed with the following result:

+1 (binding): Christian Schneider, Jamie Goodyear, Achim Nierbeck,
Jean-Baptiste Onofré
+1 (non-binding): François Papon, Grzegorz Grzybek, Toni Menzel

I'm promoting the artifacts to Central, update Jira and website, upload
releases to dist.apache.org and I will announce the release.

Thanks all for your vote,
Regards
JB

On 10/08/2018 06:58, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf (Container) 4.1.6 release to your vote (take #2 after Pax
> Web and Spring updates). This is a
> maintenance release on 4.1.x series.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1113/
> 
> Git Tag:
> karaf-4.1.6
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [VOTE] Apache Karaf (Container) 4.1.6 release - take #2

2018-08-11 Thread Jean-Baptiste Onofré
+1 (binding)

Regards
JB

On 10/08/2018 06:58, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf (Container) 4.1.6 release to your vote (take #2 after Pax
> Web and Spring updates). This is a
> maintenance release on 4.1.x series.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1113/
> 
> Git Tag:
> karaf-4.1.6
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[VOTE] Apache Karaf (Container) 4.1.6 release - take #2

2018-08-09 Thread Jean-Baptiste Onofré
Hi all,

I submit Karaf (Container) 4.1.6 release to your vote (take #2 after Pax
Web and Spring updates). This is a
maintenance release on 4.1.x series.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1113/

Git Tag:
karaf-4.1.6

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [IRC] - spam

2018-08-08 Thread Jean-Baptiste Onofré
Hi François,

I saw that as well and notified freenode, but didn't get any feedback.

I gonna ban the nick providing spam.

Regards
JB

On 08/08/2018 12:53, Francois Papon wrote:
> Hi,
> 
> We have a lot of spam on the IRC channel, is there a way to hide them in
> the channel admin ?
> 
> regards,
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[CANCEL][VOTE] Apache Karaf (Container) 4.1.6 release

2018-08-07 Thread Jean-Baptiste Onofré
Hi all,

unfortunately, due to https://issues.apache.org/jira/browse/KARAF-5860 I
cancel this vote.

An important security issue has been found in Jetty (see
https://securitytracker.com/id/1041194). This issue has been fixed in
Jetty 9.3.24.v20180605 and 9.4.11.v20180605.

I will prepare two new Pax Web releases:
- Pax Web 6.0.11 for Karaf 4.1.6 with Jetty 9.3.24.v20180605 update
- Pax Web 7.2.3 for Karaf 4.2.1 with Jetty 9.4.11.v20180605 update

I'm working on this tonight and I will submit Karaf 4.1.6 take #2
release tomorrow.

Sorry about that.

Regards
JB

On 03/08/2018 19:20, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf (Container) 4.1.6 release to your vote. This is a
> maintenance release on 4.1.x series.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1112/
> 
> Git Tag:
> karaf-4.1.6
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Latest configadmin in Karaf 4.2.1

2018-08-05 Thread Jean-Baptiste Onofré
https://issues.apache.org/jira/browse/KARAF-5859 ;)

By the way, I'm adding the new examples in the itests and polishing
examples themselves and dev guide a bit and I will submit the release to
vote.

Regards
JB

On 05/08/2018 17:47, Eric Lilja wrote:
> Ah, very nice to see, thanks for your awesome work! Any chance to get
> the latest hibernate validator as well (6.0.11.Final)?
> 
> - EL
> 
> On 2018-08-05 17:38, Jean-Baptiste Onofré wrote:
>> See:
>>
>> https://issues.apache.org/jira/browse/KARAF-5858
>>
>> The PR is on the way.
>>
>> Regards
>> JB
>>
>> On 05/08/2018 13:31, Eric Lilja wrote:
>>> Hi, many of us are highly anticipating the upcoming Karaf 4.2.1 release!
>>> Thanks for all your work to those involved! It is possible it could
>>> include the newly released org.apache.felix.configadmin version 1.9.4?
>>>
>>> Best wishes to all
>>>
>>> - EL
>>>
> 


Re: Latest configadmin in Karaf 4.2.1

2018-08-05 Thread Jean-Baptiste Onofré
On the way as well ;)

Thanks !

Regards
JB

On 05/08/2018 17:47, Eric Lilja wrote:
> Ah, very nice to see, thanks for your awesome work! Any chance to get
> the latest hibernate validator as well (6.0.11.Final)?
> 
> - EL
> 
> On 2018-08-05 17:38, Jean-Baptiste Onofré wrote:
>> See:
>>
>> https://issues.apache.org/jira/browse/KARAF-5858
>>
>> The PR is on the way.
>>
>> Regards
>> JB
>>
>> On 05/08/2018 13:31, Eric Lilja wrote:
>>> Hi, many of us are highly anticipating the upcoming Karaf 4.2.1 release!
>>> Thanks for all your work to those involved! It is possible it could
>>> include the newly released org.apache.felix.configadmin version 1.9.4?
>>>
>>> Best wishes to all
>>>
>>> - EL
>>>
> 


Re: [VOTE] Apache Karaf (Container) 4.1.6 release

2018-08-05 Thread Jean-Baptiste Onofré
+1 (binding)

Regards
JB

On 03/08/2018 19:20, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I submit Karaf (Container) 4.1.6 release to your vote. This is a
> maintenance release on 4.1.x series.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1112/
> 
> Git Tag:
> karaf-4.1.6
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Latest configadmin in Karaf 4.2.1

2018-08-05 Thread Jean-Baptiste Onofré
See:

https://issues.apache.org/jira/browse/KARAF-5858

The PR is on the way.

Regards
JB

On 05/08/2018 13:31, Eric Lilja wrote:
> Hi, many of us are highly anticipating the upcoming Karaf 4.2.1 release!
> Thanks for all your work to those involved! It is possible it could
> include the newly released org.apache.felix.configadmin version 1.9.4?
> 
> Best wishes to all
> 
> - EL
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Latest configadmin in Karaf 4.2.1

2018-08-05 Thread Jean-Baptiste Onofré
Yes, already planned.

Regards
JB

On 05/08/2018 13:31, Eric Lilja wrote:
> Hi, many of us are highly anticipating the upcoming Karaf 4.2.1 release!
> Thanks for all your work to those involved! It is possible it could
> include the newly released org.apache.felix.configadmin version 1.9.4?
> 
> Best wishes to all
> 
> - EL
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[VOTE] Apache Karaf (Container) 4.1.6 release

2018-08-03 Thread Jean-Baptiste Onofré
Hi all,

I submit Karaf (Container) 4.1.6 release to your vote. This is a
maintenance release on 4.1.x series.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140=12342748

Staging Repository:
https://repository.apache.org/content/repositories/orgapachekaraf-1112/

Git Tag:
karaf-4.1.6

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [PROPOSAL] - Jenkins build

2018-07-30 Thread Jean-Baptiste Onofré
Hi,

So basically, it means creating a build pipeline per build job.

It sounds good to me. I think it makes sense to do that for master and
PR build.

I can do the changes once Karaf 4.2.1 is out.

Thanks
Regards
JB

On 31/07/2018 06:48, Francois Papon wrote:
> Hi,
> 
> With the new livecycle of JDK releases (9,10,11,GraalVM..), I think we
> could add some JDK dedicated build on the Jenkins like this :
> 
> https://builds.apache.org/job/maven-box/job/maven-pdf-plugin/job/master/
> 
> Now that we have some examples include in the itests, it's more
> convenient to have a check of the JDK compatibility.
> 
> Thoughts ?
> 
> regards,
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: JUnit test failure when playing with time zones

2018-07-30 Thread Jean-Baptiste Onofré
Thanks for the report.

AFAIR, we already did a couple of fixes around that.

Let me check.

Regards
JB

On 30/07/2018 17:36, Lukasz Lech wrote:
> Hello,
> 
> After  pulling master of apache/karaf I've noticed test failure. Under Linux 
> it fails in Audit :: Core  :
> 
> [ERROR] testFileSize(org.apache.karaf.audit.logger.EventLoggerTest)  Time 
> elapsed: 0.118 s  <<< FAILURE!
> java.lang.AssertionError: expected:<[file-2017-11-17-2.log, 
> file-2017-11-17.log, file.log]> but was:<[file-2017-11-18-2.log, 
> file-2017-11-18.log, file.log]>
> at 
> org.apache.karaf.audit.logger.EventLoggerTest.testFileSize(EventLoggerTest.java:230)
> 
> I've forgotten that I've played with my time zone and set it to New Zealand 
> (in order to test our application if it deals correctly with 
> non-central-european time zones). After switching to CEST the tests run 
> correctly, however, being in CEST I'm now in the same day as GMT. I'm not 
> sure if Java somehow 'know' that time zone set by timedatectl is not my 
> 'real' time zone (for example, by saving original timezone somewhere during 
> installation) and the problem would not occur for people that are really in 
> New Zealand, but I feel that Junit tests shouldn't fail because of such 
> configuration.
> 
> Could someone from that region (or working very late) check if the test fail 
> always when GMT shows other day than local time?
> 
> Btw.  On Windows build fails (it was always failing, but anytime in other 
> place). This time in :
> [ERROR] Errors:
> [ERROR]   ProfilesTest.testProfilesApi:75 ▒ IllegalArgument character to be 
> escaped is m...
> (Profile :: Core)
> 
> Best regards,
> Lukasz Lech
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[UPDATE] New docker feature, new docker resources and official images

2018-07-28 Thread Jean-Baptiste Onofré
Hi guys,

as you might know, I worked on a new docker feature for Karaf.

The current work is here:

https://github.com/apache/karaf/pull/546

This branch is almost done and contains:

1. The docker resources allowing users to easily create Karaf Docker
image and start it.
2. The new docker feature (as part of the enterprise features
repository) allowing you to interact with docker directly from Karaf and
do a provisioning.

You can take a look on the updated user guide about docker to have a
complete overview:

https://github.com/jbonofre/karaf/blob/1b748eafe8e290df76bfd0c3c02af7051701dce0/manual/src/main/asciidoc/user-guide/docker.adoc

As part of the release process (starting from  4.2.1), I propose to
publish official Karaf image on Docker HUB.

I'm also preparing a blog post about that.

If you have any question or comment, please let me know. I plan to merge
the PR pretty soon.

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [UPDATE] Apache Karaf 4.2.1 on vote soon and master moving to 4.3.0-SNAPSHOT

2018-07-24 Thread Jean-Baptiste Onofré
Hi guys,

we are now on the latest steps in Karaf "Container" 4.2.1 release
preparation.

I'm updating, fixing and reviewing the last PRs.

I plan to start the release process during the week end, so 4.2.1 should
be in vote on Sunday or Monday.

Regards
JB

On 12/07/2018 09:05, Jean-Baptiste Onofré wrote:
> Hi guys,
> 
> maybe you see some updates on Jira: I have a bunch of local branches
> ready as PRs to prepare Karaf 4.2.1.
> 
> It's almost done, and I'm pretty confident that 4.2.1 will be on vote
> before the end of this week.
> 
> On the other hand, when 4.2.1 will be out, I will create the 4.2.x
> branch and master will be bumped to 4.3.0-SNAPSHOT.
> The purpose of 4.3.x is to have fully R7 support (which is partial for
> now on 4.2.x).
> 
> Regards
> JB
> 


Re: issues while using Spring 5.0.4 with latest KARAF 4.2.0

2018-07-23 Thread Jean-Baptiste Onofré
Hi Munish,

by the way, any blocking point to use blueprint instead of Spring ? Are
you using lot of spring extensions ?
I'm just curious ;)

Regards
JB

On 23/07/2018 13:50, munishgupta.asr wrote:
> Thanks Guillaume for providing information. I was trying for last 3 days to
> find any reference documentation  which could give me a clue about web
> support.
> 
> I have created a JIRA Ticket and here is the number (Web.XML Attached)
> https://issues.apache.org/jira/browse/ARIES-1819
> 
> Meanwhile, can you please suggest me any workaround to get the web APP
> running (Spring-MVC) on KARAF 4.2.0 and Spring 5.0.X combination?
> 
> 
> Regards
> Munish
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 


Re: issues while using Spring 5.0.4 with latest KARAF 4.2.0

2018-07-23 Thread Jean-Baptiste Onofré
Hi

It's what I remembered about the spring 5 support.

Do we have a jira already about that ?

Regards
JB

Le 23 juil. 2018 à 12:26, à 12:26, Guillaume Nodet  a écrit:
>Sorry, the web part is definitely not implemented.
>Could you raise a JIRA issue in the Aries Blueprint project and maybe
>attach your simple web app and I'll have a look asap.
>
>Guillaume
>
>Le dim. 22 juil. 2018 à 12:35, munishgupta.asr
>
>a écrit :
>
>> Thanks Guillaume Nodet-2,
>>
>> I have installed and started 3 blueprint bundles.
>>  75 | Active   |  80 | 0.6.0  | Apache Aries Blueprint
>Spring
>>  76 | Active   |  80 | 0.4.0  | Apache Aries Blueprint
>Spring
>> Extender
>>  77 | Active   |  80 | 1.0.1  | Apache Aries Blueprint
>Web OSGI
>>
>> first I was not able to see my web application (Spring-MVC) open at
>all and
>> it was throwing wiring exceptions to identify org.springframework
>related
>> exceptions.
>>
>> Later I commented spring-dm related entry in web.xml and added new
>entry
>> for
>> blueprint context listener.
>>
>> **
>> //Added
>> 
>> 
>>   org.apache.aries.blueprint.web.BlueprintContextListener
>> 
>>  
>>
>> **
>> // commented
>>  
>> 
>>   org.springframework.web.context.ContextLoaderListener
>> 
>>   
>>   
>> audit
>>
>>
>>
>org.springframework.web.servlet.DispatcherServlet
>> 
>> contextClass
>> 
>>
>>
>>
>org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext
>> 
>> 
>>   
>> **
>>
>> with that, now I am able to see root JSP page opening but on any
>action, it
>> is not hitting controller classes. How i need to handle the servlet
>related
>> configuration defined in web.XML with aries-blueprint?
>>
>> Can you please guide? in case if you have any sample programme, that
>would
>> be too helpful.
>> My concern is that I am not finding how to handle change in web.xml
>> (changing spring-dm related classes to aries-blueprint).
>>
>> Thanks in Advance
>> Munish
>>
>>
>>
>> --
>> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
>>
>
>
>--
>
>Guillaume Nodet


[INFO] Update on Jenkins builds

2018-07-19 Thread Jean-Baptiste Onofré
Hi guys,

maybe you saw some instability on the Jenkins builds recently.

It's related to several causes:
1. Some Jenkins executors were not working (filesystem full)
2. Other Jenkins executors were very slow, causing our build canceled
due to timeout
3. Couple of flacky tests

I changed the executors pool and it's now better. I also increased the
build timeout as workaround for slow executors.

I also created the Jira related to flacky test, I'm working on it.

Sorry for the inconvenience, it should be better now.

I'm now merging bunch of PR in preparation for Karaf Container 4.2.1.

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: issues while using Spring 5.0.4 with latest KARAF 4.2.0

2018-07-18 Thread Jean-Baptiste Onofré
Hi Munish,

spring-osgi (spring-dm) doesn't support Spring 5.

So, if you want to use spring-dm, you are stuck with Spring 4: no other
way. In Karaf 4.2.0 vanilla distribution, it works because we provide
several spring versions, and when you install spring-dm  feature, it
installs spring 4.0.x.

I recommend you to update to blueprint (replacement of spring-dm).

Regards
JB

On 18/07/2018 14:37, munishgupta.asr wrote:
> Hi All,
> 
> We are using KARAF 4.0.0 for now and trying to upgrade it to 4.2.0 now. We
> are also upgrading jetty libraries to latest supported version and upgraded
> spring version to 5.0.4 Release.
> 
> for using Spring on OSGI, currently we were using 'spring-osgi-web' and
> 'spring-osgi-core' libraries of 'org.springframework.osgi;  with version as
> 1.2.1. 
> 
> After upgrade, it seems these libraries are only supported upto Spring
> Version 4.0.0 and not further.
> 
> Can you please guide me what i should be trying for using Spring 5.0.4 on
> latest KARAF 4.2.0?
> 
> Regards
> Munish 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[UPDATE] Apache Karaf 4.2.1 on vote soon and master moving to 4.3.0-SNAPSHOT

2018-07-12 Thread Jean-Baptiste Onofré
Hi guys,

maybe you see some updates on Jira: I have a bunch of local branches
ready as PRs to prepare Karaf 4.2.1.

It's almost done, and I'm pretty confident that 4.2.1 will be on vote
before the end of this week.

On the other hand, when 4.2.1 will be out, I will create the 4.2.x
branch and master will be bumped to 4.3.0-SNAPSHOT.
The purpose of 4.3.x is to have fully R7 support (which is partial for
now on 4.2.x).

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Preparing Karaf 4.2.1 and some ideas

2018-07-05 Thread Jean-Baptiste Onofré
Hi guys,

just to let you know that 4.2.1 preparation is on the way (SNAPSHOT
dependencies have been resolved, example and docker feature/image will
be in PR soon).

I plan to submit the release to vote soon (probably during the weekend
or beginning of next week).

Regards
JB

On 17/06/2018 17:17, Jean-Baptiste Onofré wrote:
> Hi guys,
> 
> As I started to prepare Karaf 4.2.1, I rebased and cleaned up the
> examples. The corresponding PR is there:
> 
> https://github.com/apache/karaf/pull/484
> 
> As already mention on the mailing list, I gonna add new examples asked
> by users. It seems also that lot of users has difficulties to create
> their own Karaf distro. I will add new examples around that (there is
> already one), and I think we can improve the karaf-maven-plugin to
> simplify the way of creating distribution, and give the right example
> (the generate MOJO is more a source of problem and we should encourage
> users to write their features XML IMHO).
> 
> On the other hand, I started a branch where I refactored the README and
> other documentation file to use the md format. The advantages of md
> (compare to raw text or ascii doc) is that:
> 1. It can be rendered directly on github
> 2. The doxia maven plugin supports it by default (no need to use
> asciidoc specific plugin)
> 3. It's a well known format
> 
> We are moving forward on this and other Jira (starting the triage right
> now) and hopefully, Karaf 4.2.1 will be submitted to vote soon-"ish"
> (middle of this week).
> 
> Regards
> JB
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [REMINDER] Avoid SNAPSHOT when possible

2018-07-05 Thread Jean-Baptiste Onofré
Hi Steinar,

you have to change your import package version range as Karaf 4.2.x now
use Pax Web 7.x.

Your import is:

org.ops4j.pax.web.service;version="[6.0,7)"

it should be:

org.ops4j.pax.web.service;version="[6,8)"

Regards
JB

On 05/07/2018 20:44, Steinar Bang wrote:
>>>>>> Jean-Baptiste Onofré :
> 
>> just a little reminder: when possible, please avoid to use SNAPSHOT in
>> dependency (or only on PR, not merged on master).
> 
>> SNAPSHOT dependencies breaks the build and so Karaf SNAPSHOTs are not
>> deployed anymore.
>> It also block release as we can't release project containing SNAPSHOT
>> dependencies.
> 
>> For instance, we did a commit on master this morning upgrading to
>> Easymock 3.7-SNAPSHOT (to be able to build with Java 10/11), and Jenkins
>> is broken (also local build).
> 
>> I will fix that, but, please, keep in mind to avoid SNAPSHOT
>> dependencies when possible.
> 
> Ah... I tried my app today for the first time on 4.2.0, specifically
> this branch (where all the current work takes place):
>  https://github.com/steinarb/ukelonn/tree/using-react
> 
> The app was built with karaf-maven-plugin 4.1.2, and pax exam karaf
> 4.1.2 integration tests, and running fine on 4.1.5.
> 
> But one of the bundles refused to load on karaf 4.2.0, complaining about
> a missing dependency that already was satisfied for another bundle.
> 
> I'm building with maven version 1.0.0-SNAPSHOT, so I'm wondering if that
> is the reason for the failure?
> 
> Here are the karaf console commads that led up to the error (requires
> cloning and building the above repo):
> 
> karaf@root()> feature:repo-add 
> mvn:no.priv.bang.ukelonn/karaf/LATEST/xml/features
> Adding feature url mvn:no.priv.bang.ukelonn/karaf/LATEST/xml/features
> karaf@root()> feature:install ukelonn-db-derby-test
> karaf@root()> feature:install ukelonn
> org.osgi.service.resolver.ResolutionException: Unable to resolve root: 
> missing requirement [root] osgi.identity; osgi.identity=ukelonn; 
> type=karaf.feature; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=ukelonn)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
>  [caused by: Unable to resolve ukelonn/1.0.0.SNAPSHOT: missing requirement 
> [ukelonn/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=no.priv.bang.ukelonn; 
> type=osgi.bundle; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> resolution:=mandatory [caused by: Unable to resolve 
> no.priv.bang.ukelonn/1.0.0.SNAPSHOT: missing requirement 
> [no.priv.bang.ukelonn/1.0.0.SNAPSHOT] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.ops4j.pax.web.service)(version>=6.0.0)(!(version>=7.0.0)))"]]
> at 
> org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)
> at 
> org.apache.felix.resolver.ResolverImpl.doResolve(ResolverImpl.java:391)
> at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:377)
> at 
> org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:331)
> at 
> org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:248)
> at 
> org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:388)
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1025)
> at 
> org.apache.karaf.features.internal.service.FeaturesServiceImpl.lambda$doProvisionInThread$13(FeaturesServiceImpl.java:964)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Error executing command: Unable to resolve root: missing requirement [root] 
> osgi.identity; osgi.identity=ukelonn; type=karaf.feature; 
> version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> filter:="(&(osgi.identity=ukelonn)(type=karaf.feature)(version>=1.0.0.SNAPSHOT)(version<=1.0.0.SNAPSHOT))"
>  [caused by: Unable to resolve ukelonn/1.0.0.SNAPSHOT: missing requirement 
> [ukelonn/1.0.0.SNAPSHOT] osgi.identity; osgi.identity=no.priv.bang.ukelonn; 
> type=osgi.bundle; version="[1.0.0.SNAPSHOT,1.0.0.SNAPSHOT]"; 
> resolution:=mandatory [caused by: Unable to resolve 
> no.priv.bang.ukelonn/1.0.0.SNAPSHOT: missing requirement 
> [no.priv.bang.ukelonn/1.0.0.SNAPSHOT] osgi.wiring.package; 
> filter:="(&(osgi.wiring.package=org.ops4j.pax.web.service)(version>

Re: [REMINDER] Avoid SNAPSHOT when possible

2018-07-05 Thread Jean-Baptiste Onofré
Thanks Freeman and not a problem at all !

I downgraded to Easymock 3.6 and created the Jira to track the update
when available.

Regards
JB

On 05/07/2018 13:44, Freeman Fang wrote:
> Hi JB,
> 
> Sorry I introduced the easy mock SNAPSHOT. Per the discussion here[1], 
> easymock 3.7 release which can work with JDK11 should not be far.
> 
> Anyway, we can downgrade to easymock 3.6 so far while waiting for easymock 
> 3.7 release. Though this will cause VerifyMojoTest failed with JDK11, I will 
> add a profile to disable this test with JDK11 until we have easymock 3.7 
> available.
> 
> Btw, could we also have CI build for master using JDK10 and JDK11; therefore 
> we can catch any test failure in the first time.
> [1]https://github.com/easymock/easymock/issues/218 
> <https://github.com/easymock/easymock/issues/218>
> 
> Cheers
> -
> Freeman(Yue) Fang
> 
> Red Hat, Inc. 
> FuseSource is now part of Red Hat
> 
> 
> 
>> On Jul 5, 2018, at 4:50 PM, Jean-Baptiste Onofré  wrote:
>>
>> Hi guys,
>>
>> just a little reminder: when possible, please avoid to use SNAPSHOT in
>> dependency (or only on PR, not merged on master).
>>
>> SNAPSHOT dependencies breaks the build and so Karaf SNAPSHOTs are not
>> deployed anymore.
>> It also block release as we can't release project containing SNAPSHOT
>> dependencies.
>>
>> For instance, we did a commit on master this morning upgrading to
>> Easymock 3.7-SNAPSHOT (to be able to build with Java 10/11), and Jenkins
>> is broken (also local build).
>>
>> I will fix that, but, please, keep in mind to avoid SNAPSHOT
>> dependencies when possible.
>>
>> Thanks !
>> Regards
>> JB
>> -- 
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
> 
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[REMINDER] Avoid SNAPSHOT when possible

2018-07-05 Thread Jean-Baptiste Onofré
Hi guys,

just a little reminder: when possible, please avoid to use SNAPSHOT in
dependency (or only on PR, not merged on master).

SNAPSHOT dependencies breaks the build and so Karaf SNAPSHOTs are not
deployed anymore.
It also block release as we can't release project containing SNAPSHOT
dependencies.

For instance, we did a commit on master this morning upgrading to
Easymock 3.7-SNAPSHOT (to be able to build with Java 10/11), and Jenkins
is broken (also local build).

I will fix that, but, please, keep in mind to avoid SNAPSHOT
dependencies when possible.

Thanks !
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: [FYI] temporary branch for OSGi Core r7 upgrade

2018-07-04 Thread Jean-Baptiste Onofré
Thanks

Agree to Target r7 for Karaf 4.3.x.

Anyway 4.2.1 will be in vote soon (working on it).

Regards
JB

Le 4 juil. 2018 à 11:39, à 11:39, Guillaume Nodet  a écrit:
>I've created a temporary branch for the upgrade to OSGi Core r7 (well,
>felix framework 6.0, currently under vote).
>I think this should be targeted for Karaf 4.3, but it's still missing
>an
>update for equinox.
>Anyway, I didn't want to drop the branch I used to test the felix
>release
>so I've uploaded it there:
>   https://github.com/apache/karaf/tree/osgi-r7
>
>--
>
>Guillaume Nodet


Re: Official Docker image for karaf

2018-06-19 Thread Jean-Baptiste Onofré
Hi,

I'm preparing one on the Apache DockerHub. It's part of the docker
feature PR on which I'm working (based on
https://github.com/jbonofre/karaf-docker). So the docker file will be
part of the build.

I keep you posted (we have a Jira about that).

Regards
JB

On 19/06/2018 13:01, imranrazakhan wrote:
> Do we have official docker image for karaf?
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-Dev-f930721.html
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: Preparing Karaf 4.2.1 and some ideas

2018-06-17 Thread Jean-Baptiste Onofré
I think that's fair for some use cases, but generally speaking, we
should improve the global usage.

scope (compile, runtime, provided) is not well used, kar requirement is
overhead, the generate mojo is not accurate, etc.

I would propose the following:
1. Deprecate the generate features mojo to promote the by-hand features
2. Improve the assembly mojo to use   in a easier way

I will come with a concrete proposal around that.

Regards
JB

On 17/06/2018 17:45, Grzegorz Grzybek wrote:
> Hello
> 
> At some point I'm going to "fix"
> https://issues.apache.org/jira/browse/KARAF-5540 which is a documentation
> issue of new "overrides and blacklisting" mechanism.
> 
> In fact this mechanism was created from "custom distro" point of view and
> some fixes/changes make things easier with custom distributions.
> 
> best regards
> Grzegorz Grzybek
> 
> 2018-06-17 17:17 GMT+02:00 Jean-Baptiste Onofré :
> 
>> Hi guys,
>>
>> As I started to prepare Karaf 4.2.1, I rebased and cleaned up the
>> examples. The corresponding PR is there:
>>
>> https://github.com/apache/karaf/pull/484
>>
>> As already mention on the mailing list, I gonna add new examples asked
>> by users. It seems also that lot of users has difficulties to create
>> their own Karaf distro. I will add new examples around that (there is
>> already one), and I think we can improve the karaf-maven-plugin to
>> simplify the way of creating distribution, and give the right example
>> (the generate MOJO is more a source of problem and we should encourage
>> users to write their features XML IMHO).
>>
>> On the other hand, I started a branch where I refactored the README and
>> other documentation file to use the md format. The advantages of md
>> (compare to raw text or ascii doc) is that:
>> 1. It can be rendered directly on github
>> 2. The doxia maven plugin supports it by default (no need to use
>> asciidoc specific plugin)
>> 3. It's a well known format
>>
>> We are moving forward on this and other Jira (starting the triage right
>> now) and hopefully, Karaf 4.2.1 will be submitted to vote soon-"ish"
>> (middle of this week).
>>
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Preparing Karaf 4.2.1 and some ideas

2018-06-17 Thread Jean-Baptiste Onofré
Hi guys,

As I started to prepare Karaf 4.2.1, I rebased and cleaned up the
examples. The corresponding PR is there:

https://github.com/apache/karaf/pull/484

As already mention on the mailing list, I gonna add new examples asked
by users. It seems also that lot of users has difficulties to create
their own Karaf distro. I will add new examples around that (there is
already one), and I think we can improve the karaf-maven-plugin to
simplify the way of creating distribution, and give the right example
(the generate MOJO is more a source of problem and we should encourage
users to write their features XML IMHO).

On the other hand, I started a branch where I refactored the README and
other documentation file to use the md format. The advantages of md
(compare to raw text or ascii doc) is that:
1. It can be rendered directly on github
2. The doxia maven plugin supports it by default (no need to use
asciidoc specific plugin)
3. It's a well known format

We are moving forward on this and other Jira (starting the triage right
now) and hopefully, Karaf 4.2.1 will be submitted to vote soon-"ish"
(middle of this week).

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[REPORT] Apache Karaf

2018-06-14 Thread Jean-Baptiste Onofré
## Description:
 - Apache Karaf provides a very modern and polymorphic container,
multi-purpose (microservices, OSGi, etc) powered by OSGi.

## Issues:
 - There are no issue requiring board attention at this time

## Activity:
 - We released new major milestone: 4.2.0, it's an very important step
forward in our release cycle.
 - We revamped the website and created a #karaf room on The ASF Slack
 - We are preparing new Cave and Decanter releases, including new
features requested by users
 - We still have lot of interactions with other communities from Apache
(from Apache, like jclouds, sling), and others (OpenHAB, OpenDaylight, ...)

## Health report:
 - We can note increased messages and feedback from users.

## PMC changes:
 - Currently 15 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Christian Schneider on Mon Aug 22 2016

## Committer base changes:
 - Currently 31 committers.
 - Francois Papon was added as a committer on Sat May 19 2018

## Releases:
 - 4.2.0 was released on Mon Apr 09 2018

## Mailing list activity:
 We can note a constant activity.

 - dev@karaf.apache.org:
- 185 subscribers (down -4 in the last 3 months):
- 148 emails sent to list (223 in previous quarter)

 - iss...@karaf.apache.org:
- 43 subscribers (up 1 in the last 3 months):
- 909 emails sent to list (1219 in previous quarter)

 - u...@karaf.apache.org:
- 363 subscribers (down -10 in the last 3 months):
- 481 emails sent to list (434 in previous quarter)

## JIRA activity:
 - 117 JIRA tickets created in the last 3 months
 - 91 JIRA tickets closed/resolved in the last 3 months


[June 18] Board report

2018-06-13 Thread Jean-Baptiste Onofré
Hi guys,

I prepared the board report for this month:

https://cwiki.apache.org/confluence/display/KARAF/Board+Reports

Please, review quickly, I would like to send pretty fast (tomorrow).

Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


[ANN] Update on Karaf website, and creation of the #karaf slack channel

2018-06-12 Thread Jean-Baptiste Onofré
Hi,

The Karaf team is pleased to announce an upgrade on the Karaf website:

http://karaf.apache.org

You can see now:
- an updated look'n feel leveraging bootstrap
- updated documentation providing preview on examples we are preparing
in the Karaf distribution
- updated contribution guide (around pull requests as we moved to gitbox)

You can also see the creation of the #karaf room on the-asf official
slack (the-asf.slack.com).

Enjoy !

NB: a huge thank to François for the work he did on the website !
-- 
The Karaf Team


[ANN] New Karaf committer: François Papon

2018-06-02 Thread Jean-Baptiste Onofré
Please join me and the rest of the Karaf PMC members in welcoming our
new Karaf committer: François Papon.
François is a big Karaf fan, he has contributed to the project in
different ways (website, decanter, examples, and much more) and we look
forward to many more contributions in the future.

Congratulations to François! Welcome!

Regards
JB
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com


Re: https://github.com/apache/karaf/pull/504

2018-05-24 Thread Jean-Baptiste Onofré
It has been merged.

Thanks for your contribution !

Regards
JB

On 24/05/2018 13:44, Baptiste Da Roit wrote:
> Hi,
> 
>  
> 
> As advised in the contribution page, I allow myself to send this mail to
> ask if someone can take the time to review and validate the PR #504.
>  
> 
>  
> 
> Thank you for your help.
> 
>  
> 
> Cordialement / Mit freundlichen Grüßen / Kind regards
> *Baptiste DA ROIT***
> /SysAdmin / DevOps - *Research & Development / Production*/
> 
> /Les Espaces de Sophia - Batiment N - 80, Route des Lucioles/
> 
> /06560 Valbonne - Sophia-Antipolis/
> 
> cid:image001.png@01D31CD7.24FFDA10
> 
> Mobile: +33 6 88 14 81 04 
> 
> Mail: baptiste.dar...@aspera.com 
> 
> *cid:image003.png@01D0F40A.B5336900*
> 
>  
> 


Re: https://github.com/apache/karaf/pull/504

2018-05-24 Thread Jean-Baptiste Onofré
Hi,

I'm on it right now.

Regards
JB

On 24/05/2018 13:44, Baptiste Da Roit wrote:
> Hi,
> 
>  
> 
> As advised in the contribution page, I allow myself to send this mail to
> ask if someone can take the time to review and validate the PR #504.
>  
> 
>  
> 
> Thank you for your help.
> 
>  
> 
> Cordialement / Mit freundlichen Grüßen / Kind regards
> *Baptiste DA ROIT***
> /SysAdmin / DevOps - *Research & Development / Production*/
> 
> /Les Espaces de Sophia - Batiment N - 80, Route des Lucioles/
> 
> /06560 Valbonne - Sophia-Antipolis/
> 
> cid:image001.png@01D31CD7.24FFDA10
> 
> Mobile: +33 6 88 14 81 04 
> 
> Mail: baptiste.dar...@aspera.com 
> 
> *cid:image003.png@01D0F40A.B5336900*
> 
>  
> 


  1   2   3   4   5   6   7   8   9   10   >