Re: [PROPOSAL] Karaf 3.0.1 and 2.4.0 release schedule

[Jean-Baptiste Onofré]

Agree, we gonna deal with that together.

Regards
JB

On 02/18/2014 11:41 PM, Achim Nierbeck wrote:

For Karaf 3.0.1 I would really like to see [1] fixed.
Though I'm not sure if it's all Karaf but maybe also Pax Web related.


regards, Achim

[1] - https://issues.apache.org/jira/browse/KARAF-2768


2014-02-18 Giuseppe Gerla :


Hi JB
in the next release, do you fix also
KARAF-2453
?
If you need some help about it, I'm available


regards
Giuseppe



2014-02-18 15:44 GMT+01:00 Jean-Baptiste Onofré :


Hi all,

Now that we released Karaf 2.3.4, I would like to propose a schedule for
the next expected releases:

- Karaf 3.0.1 is a bug fix release on top of 3.0.0. We have one "blocker"
issue for this release (about the bundle cache corruption with Felix
Framework 4.2.0), I started to work on it, I will resume tonight. I plan

to

push some changes from my local branches, especially a lot of

improvements

on the maven-karaf-plugin, including new goals.
I propose to aim 3.0.1 for the first week on March.
- Karaf 2.4.0 is an upgrade release on top of 2.3.x. It doesn't change
some much in the Karaf core, but upgrade a lot of dependencies. I plan to
review the Jira for this release tomorrow.
I propose to release a first 2.4.0 (on the 2.x branch) just after 3.0.1
(the second week of March).

WDYT ?

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: [PROPOSAL] Karaf 3.0.1 and 2.4.0 release schedule

[Jean-Baptiste Onofré]

Hi Giuseppe,

yes it will be included (as the fixVersion is 3.0.1).

Regards
JB

On 02/18/2014 10:19 PM, Giuseppe Gerla wrote:

Hi JB
in the next release, do you fix also
KARAF-2453
?
If you need some help about it, I'm available


regards
Giuseppe



2014-02-18 15:44 GMT+01:00 Jean-Baptiste Onofré :


Hi all,

Now that we released Karaf 2.3.4, I would like to propose a schedule for
the next expected releases:

- Karaf 3.0.1 is a bug fix release on top of 3.0.0. We have one "blocker"
issue for this release (about the bundle cache corruption with Felix
Framework 4.2.0), I started to work on it, I will resume tonight. I plan to
push some changes from my local branches, especially a lot of improvements
on the maven-karaf-plugin, including new goals.
I propose to aim 3.0.1 for the first week on March.
- Karaf 2.4.0 is an upgrade release on top of 2.3.x. It doesn't change
some much in the Karaf core, but upgrade a lot of dependencies. I plan to
review the Jira for this release tomorrow.
I propose to release a first 2.4.0 (on the 2.x branch) just after 3.0.1
(the second week of March).

WDYT ?

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: [PROPOSAL] Cellar releases

[Achim Nierbeck]

Hi JB,

sounds good to me.

regards, Achim


2014-02-18 15:48 GMT+01:00 Jean-Baptiste Onofré :

> Hi all,
>
> I'm updating Cellar master branch to fully support and leverage Karaf
> 3.0.0. This branch will also include major change and update (especially
> upgrade to Hazelcast 3.1.0). I worked on a local git branch, I will merge
> and push on master starting from tomorrow night.
> I consider releasing Cellar 3.0.0 fully working with Karaf 3.0.x as a high
> priority.
> I propose to plan Cellar 3.0.0 for next middle of next week (let say
> Wednesday, February, 23).
>
> On the other hand, some fixes on Cellar master should be merged on
> cellar-2.x branch (working with Karaf 2.x). So, I propose to release Cellar
> 2.3.3 (maintenance release) just after Cellar 3.0.0 (let say end of next
> week).
>
> WDYT ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: [DISCUSS] Java DSL for writing commands

[Guillaume Nodet]

I've also added annotation support for SCR, with the injection completely
controlled by SCR
In terms of SCR, the only thing is to run the BND plugin located in
scr/support jar.  This plugin will scan our annotations and produce the
correct SCR definitions to register commands.

https://git-wip-us.apache.org/repos/asf?p=karaf.git;a=commitdiff;h=291d564eba4102a33ba79ff60a0777340ea07013
For this to work, a command class is injected into the generated bundle and
is registered as a service with the needed SCR references.  Those
references are used when instantiating the actions and injected as needed.

This means that now, most commands can be written exactly the same way with
blueprint, SCR or even no underlying DI.  We still follow our model of
Action / Command, so it's fully compatible, but much less verbose and
completely decoupled from the injection framework used.

I'm done with this work right now but opened to any comments on how to
improve this.



2014-02-17 18:29 GMT+01:00 Guillaume Nodet :

> Fwiw, I've implemented the annotation support for blueprint.
> See https://github.com/gnodet/karaf/commits/inject
> An example for the jms command is at
>
> https://github.com/gnodet/karaf/commit/9f2854da465fb55e57ec01952629e732273786a8
>
> So you're right, that if we want that level of integration for each DI
> technology, we'd have to write a layer for each one.  However:
>   * I haven't seen many different DI framework used to define commands
>   * we still have the solution I proposed in my first draf which is DI
> agnostic
>   * in the rare cases where none of the above would fit, the user can
> still use the full model (as it was the case previously with SCR), or the
> java DSL, which even if it couples a bit the service exposition to karaf,
> still removes lots of the boiler plates for common use cases
>
> Given your experiments do not seem to lead to usable results, and unless
> someone objects, I'll go ahead and commit what I have.
>
>
>
>
> 2014-02-17 17:46 GMT+01:00 Christian Schneider :
>
> Hi Guillaume
>>
>> I just tested my whiteboard approach with blueprint.
>> It seems that indeed blueprint adds a proxy even for the exported
>> service. So it is not possible to read the meta data of the Action object
>> in this case.
>> So unless there is a way to avoid the proxy creation this really speaks
>> against my solution as it would not work with blueprint.
>>
>>
>> Christian
>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>

Re: [PROPOSAL] Karaf 3.0.1 and 2.4.0 release schedule

[Achim Nierbeck]

For Karaf 3.0.1 I would really like to see [1] fixed.
Though I'm not sure if it's all Karaf but maybe also Pax Web related.


regards, Achim

[1] - https://issues.apache.org/jira/browse/KARAF-2768


2014-02-18 Giuseppe Gerla :

> Hi JB
> in the next release, do you fix also
> KARAF-2453
> ?
> If you need some help about it, I'm available
>
>
> regards
> Giuseppe
>
>
>
> 2014-02-18 15:44 GMT+01:00 Jean-Baptiste Onofré :
>
> > Hi all,
> >
> > Now that we released Karaf 2.3.4, I would like to propose a schedule for
> > the next expected releases:
> >
> > - Karaf 3.0.1 is a bug fix release on top of 3.0.0. We have one "blocker"
> > issue for this release (about the bundle cache corruption with Felix
> > Framework 4.2.0), I started to work on it, I will resume tonight. I plan
> to
> > push some changes from my local branches, especially a lot of
> improvements
> > on the maven-karaf-plugin, including new goals.
> > I propose to aim 3.0.1 for the first week on March.
> > - Karaf 2.4.0 is an upgrade release on top of 2.3.x. It doesn't change
> > some much in the Karaf core, but upgrade a lot of dependencies. I plan to
> > review the Jira for this release tomorrow.
> > I propose to release a first 2.4.0 (on the 2.x branch) just after 3.0.1
> > (the second week of March).
> >
> > WDYT ?
> >
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: [PROPOSAL] Karaf 3.0.1 and 2.4.0 release schedule

[Giuseppe Gerla]

Hi JB
in the next release, do you fix also
KARAF-2453
?
If you need some help about it, I'm available


regards
Giuseppe



2014-02-18 15:44 GMT+01:00 Jean-Baptiste Onofré :

> Hi all,
>
> Now that we released Karaf 2.3.4, I would like to propose a schedule for
> the next expected releases:
>
> - Karaf 3.0.1 is a bug fix release on top of 3.0.0. We have one "blocker"
> issue for this release (about the bundle cache corruption with Felix
> Framework 4.2.0), I started to work on it, I will resume tonight. I plan to
> push some changes from my local branches, especially a lot of improvements
> on the maven-karaf-plugin, including new goals.
> I propose to aim 3.0.1 for the first week on March.
> - Karaf 2.4.0 is an upgrade release on top of 2.3.x. It doesn't change
> some much in the Karaf core, but upgrade a lot of dependencies. I plan to
> review the Jira for this release tomorrow.
> I propose to release a first 2.4.0 (on the 2.x branch) just after 3.0.1
> (the second week of March).
>
> WDYT ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [INFO] Master doesn't build

[Jean-Baptiste Onofré]

It's now fixed.

Sorry for the inconvenience.

Regards
JB

On 02/18/2014 09:54 PM, Jean-Baptiste Onofré wrote:

Hi all,

FYI, the master compilation fails due to latest Guillaume's change
(commit 698c1398e5599d0e37feea4efe8d5654e8f47198):

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project karaf-maven-plugin: Compilation failure
[ERROR]
/home/jbonofre/workspace/karaf/karaf/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/features/InstallKarsMojo.java:[368,13]
org.apache.karaf.tooling.features.InstallKarsMojo.OfflineFeaturesService
is not abstract and does not override abstract method
getRepositoryNames() in org.apache.karaf.features.FeaturesService


The FeaturesService interface has been changed to add two new methods:

public URI getRepositoryUriFor(String name, String version);

public String[] getRepositoryNames();

but the OfflineFeaturesService implementation used in the InstallKarMojo
has not been updated.

I'm fixing that.

Regards
JB


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

Re: [INFO] Change in EIK version

[Jean-Baptiste Onofré]

That would be great !

I send an e-mail as soon as the branches are created and the SNAPSHOTs 
deployed.


Thanks a lot Giuseppe.

Regards
JB

On 02/18/2014 10:02 PM, Giuseppe Gerla wrote:

Good
I can make some test tomorrow.
I can install it and run my bundles in karaf 2.3.4 using eik.


Giuseppe


2014-02-18 21:25 GMT+01:00 Jean-Baptiste Onofré :


Hi Giuseppe,

yes, that's the purpose actually.

Regards
JB


On 02/18/2014 09:15 PM, Giuseppe Gerla wrote:


Hi JB
is the EIK 2.3.1-SNAPSHOTcompliant with Eclipse Kepler?


Giuseppe


2014-02-18 15:39 GMT+01:00 Jean-Baptiste Onofré :

  Hi all,


In order to provide EIK version working with Karaf 2.x and 3.x, I changed
the EIK version policy and branching.
Now, EIK follows the same rule as the other Karaf subprojects (Cellar and
Cave).

EIK master is now 3.0.0-SNAPSHOT and focus on the Karaf 3.0.0 support.
I gonna create a eik-2.3.x branch (starting with version 2.3.1-SNAPSHOT)
focus on Karaf 2.3.x support.

I cleaned up a bit the EIK branches: the latest EIK version on each
branch
should work with Eclipse Kepler.

I will deploy a first EIK 2.3.1-SNAPSHOT as soon as the branch is
created.

Just after, I will push the changes on master to allow EIK 3.0.0-SNAPSHOT
to work with Karaf 3.0.x. I gonna deploy a SNAPSHOT as well.

It should be done by tonight.

If some users can make a try on the SNAPSHOTs and get back to me, it
would
be great and will allow me to prepare both EIK 2.3.1 and 3.0.0 release.

Thanks in advance for your help.

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





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

Re: [INFO] Change in EIK version

[Giuseppe Gerla]

Good
I can make some test tomorrow.
I can install it and run my bundles in karaf 2.3.4 using eik.


Giuseppe


2014-02-18 21:25 GMT+01:00 Jean-Baptiste Onofré :

> Hi Giuseppe,
>
> yes, that's the purpose actually.
>
> Regards
> JB
>
>
> On 02/18/2014 09:15 PM, Giuseppe Gerla wrote:
>
>> Hi JB
>> is the EIK 2.3.1-SNAPSHOTcompliant with Eclipse Kepler?
>>
>>
>> Giuseppe
>>
>>
>> 2014-02-18 15:39 GMT+01:00 Jean-Baptiste Onofré :
>>
>>  Hi all,
>>>
>>> In order to provide EIK version working with Karaf 2.x and 3.x, I changed
>>> the EIK version policy and branching.
>>> Now, EIK follows the same rule as the other Karaf subprojects (Cellar and
>>> Cave).
>>>
>>> EIK master is now 3.0.0-SNAPSHOT and focus on the Karaf 3.0.0 support.
>>> I gonna create a eik-2.3.x branch (starting with version 2.3.1-SNAPSHOT)
>>> focus on Karaf 2.3.x support.
>>>
>>> I cleaned up a bit the EIK branches: the latest EIK version on each
>>> branch
>>> should work with Eclipse Kepler.
>>>
>>> I will deploy a first EIK 2.3.1-SNAPSHOT as soon as the branch is
>>> created.
>>>
>>> Just after, I will push the changes on master to allow EIK 3.0.0-SNAPSHOT
>>> to work with Karaf 3.0.x. I gonna deploy a SNAPSHOT as well.
>>>
>>> It should be done by tonight.
>>>
>>> If some users can make a try on the SNAPSHOTs and get back to me, it
>>> would
>>> be great and will allow me to prepare both EIK 2.3.1 and 3.0.0 release.
>>>
>>> Thanks in advance for your help.
>>>
>>> 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
>

[INFO] Master doesn't build

[Jean-Baptiste Onofré]

Hi all,

FYI, the master compilation fails due to latest Guillaume's change 
(commit 698c1398e5599d0e37feea4efe8d5654e8f47198):


[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile 
(default-compile) on project karaf-maven-plugin: Compilation failure
[ERROR] 
/home/jbonofre/workspace/karaf/karaf/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/features/InstallKarsMojo.java:[368,13] 
org.apache.karaf.tooling.features.InstallKarsMojo.OfflineFeaturesService 
is not abstract and does not override abstract method 
getRepositoryNames() in org.apache.karaf.features.FeaturesService



The FeaturesService interface has been changed to add two new methods:

   public URI getRepositoryUriFor(String name, String version);

   public String[] getRepositoryNames();

but the OfflineFeaturesService implementation used in the InstallKarMojo 
has not been updated.


I'm fixing that.

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

Re: Problem with PAX CDI features in custom distribution

[Jean-Baptiste Onofré]

FYI:

https://ops4j1.jira.com/browse/PAXCDI-81

I will tackle that tomorrow, and probably release a Pax CDI 0.6.1 to 
integrate it in next Karaf releases.


Regards
JB

On 02/18/2014 08:10 PM, Krzysztof Sobkowiak wrote:

Hi

I'm trying to upgrade the current code of ServiceMix 5 to Karaf
3.3.5-SNAPSHOT (2.3.4 fails due to the problem with hibernate-envers
feature) but I get following error while building the full assembly.

[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix  SUCCESS
[39.482s]
[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix (Minimal)
SUCCESS [28.979s]
[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix (Full)
FAILURE [4.834s]
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 1:15.916s
[INFO] Finished at: Tue Feb 18 19:48:35 CET 2014
[INFO] Final Memory: 32M/645M
[INFO]

[ERROR] Failed to execute goal
org.apache.karaf.tooling:features-maven-plugin:2.3.5-SNAPSHOT:add-features-to-repo
(add-features-to-repo) on project apache-servicemix-full: Cannot find
version for: org.apache.geronimo.specs/geronimo-jpa_2.0_spec/ -> [Help 1]

I think this is caused by one of pax cdi features referenced by Karaf
enterprise features which includes the geronimo-jpa_2.0_spec bundle with
no version.

  
 pax-cdi-deltaspike-core
mvn:org.ops4j.base/ops4j-base-monitors/1.4.0
mvn:org.ops4j.base/ops4j-base-io/1.4.0
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
*mvn:org.apache.geronimo.specs/geronimo-jpa_2.0_spec/*
 mvn:org.ops4j.pax.jpa/pax-jpa/0.1.1
mvn:org.ops4j.pax.jdbc/pax-jdbc/0.3.0
mvn:org.apache.deltaspike.modules/deltaspike-jpa-module-api/0.5

mvn:org.apache.deltaspike.modules/deltaspike-jpa-module-impl/0.5

mvn:org.ops4j.pax.cdi.fragment/pax-cdi-fragment-ds-jpa/0.6.0

   

I'm writing this mail on this list because I think this feature can
cause problems with other custom distributions based on the Karaf
releases including this features repository.

Regards
Krzysztof




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

Re: [INFO] Change in EIK version

[Jean-Baptiste Onofré]

Hi Giuseppe,

yes, that's the purpose actually.

Regards
JB

On 02/18/2014 09:15 PM, Giuseppe Gerla wrote:

Hi JB
is the EIK 2.3.1-SNAPSHOTcompliant with Eclipse Kepler?


Giuseppe


2014-02-18 15:39 GMT+01:00 Jean-Baptiste Onofré :


Hi all,

In order to provide EIK version working with Karaf 2.x and 3.x, I changed
the EIK version policy and branching.
Now, EIK follows the same rule as the other Karaf subprojects (Cellar and
Cave).

EIK master is now 3.0.0-SNAPSHOT and focus on the Karaf 3.0.0 support.
I gonna create a eik-2.3.x branch (starting with version 2.3.1-SNAPSHOT)
focus on Karaf 2.3.x support.

I cleaned up a bit the EIK branches: the latest EIK version on each branch
should work with Eclipse Kepler.

I will deploy a first EIK 2.3.1-SNAPSHOT as soon as the branch is created.

Just after, I will push the changes on master to allow EIK 3.0.0-SNAPSHOT
to work with Karaf 3.0.x. I gonna deploy a SNAPSHOT as well.

It should be done by tonight.

If some users can make a try on the SNAPSHOTs and get back to me, it would
be great and will allow me to prepare both EIK 2.3.1 and 3.0.0 release.

Thanks in advance for your help.

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: [INFO] Change in EIK version

[Giuseppe Gerla]

Hi JB
is the EIK 2.3.1-SNAPSHOTcompliant with Eclipse Kepler?


Giuseppe


2014-02-18 15:39 GMT+01:00 Jean-Baptiste Onofré :

> Hi all,
>
> In order to provide EIK version working with Karaf 2.x and 3.x, I changed
> the EIK version policy and branching.
> Now, EIK follows the same rule as the other Karaf subprojects (Cellar and
> Cave).
>
> EIK master is now 3.0.0-SNAPSHOT and focus on the Karaf 3.0.0 support.
> I gonna create a eik-2.3.x branch (starting with version 2.3.1-SNAPSHOT)
> focus on Karaf 2.3.x support.
>
> I cleaned up a bit the EIK branches: the latest EIK version on each branch
> should work with Eclipse Kepler.
>
> I will deploy a first EIK 2.3.1-SNAPSHOT as soon as the branch is created.
>
> Just after, I will push the changes on master to allow EIK 3.0.0-SNAPSHOT
> to work with Karaf 3.0.x. I gonna deploy a SNAPSHOT as well.
>
> It should be done by tonight.
>
> If some users can make a try on the SNAPSHOTs and get back to me, it would
> be great and will allow me to prepare both EIK 2.3.1 and 3.0.0 release.
>
> Thanks in advance for your help.
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [PROPOSAL] Include samples and new dev guide for Karaf 3.0.1

[Jean-Baptiste Onofré]

For now, keep the samples in Karaf (directly under samples module as I 
have prepared).


I will move all in a row when creating the new subproject (it's 
something that I would like to discuss and vote on the dev mailing list 
first).


Regards
JB

On 02/18/2014 08:31 PM, Krzysztof Sobkowiak wrote:

Hi Jean-Baotiste

I'd like to heslp too with the samples. I'd like to do some work for
ServiceMix this (and probably next) week. Next I could find some time
for the samples.

I have another question. You plat to extract the enterprise features
into a separate subproject. Will be the samples using the enterprise
features implemented in Karaf or in the subproject?

Regards
Krzysztof

On 18.02.2014 18:16, Jean-Baptiste Onofré wrote:

Hi all,

You probably saw that we did a good job in the quickstart, update
notes, and user guide for Karaf 3.0.0:
http://karaf.apache.org/manual/latest/quick-start.html
http://karaf.apache.org/manual/latest/update-notes.html
http://karaf.apache.org/manual/latest/users-guide/index.html

I started to work on a complete refactoring of the dev guide on a
local git branch.
I already started to discussed with Christian to provide dev examples
directly in the Karaf distribution. It's a refactoring and huge
extension to the existing demo folder.

The purpose is illustrate the content in the dev guide with "real"
examples, covering all Karaf features (especially the enterprise ones,
like JPA, CDI, etc).

I will push the samples module structure.
Christian already said he's in to help, but any help is welcome ;)

I should be able to push the structure and samples frame tonight.

Thanks in advance for your help.

Regards
JB





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

Re: Problem with PAX CDI features in custom distribution

[Jean-Baptiste Onofré]

Basically, it's a mistake in the feature, as the version is not set for 
jpa spec bundle.


I'm fixing that on CDI side.

Thanks for the report.

Regards
JB

On 02/18/2014 08:10 PM, Krzysztof Sobkowiak wrote:

Hi

I'm trying to upgrade the current code of ServiceMix 5 to Karaf
3.3.5-SNAPSHOT (2.3.4 fails due to the problem with hibernate-envers
feature) but I get following error while building the full assembly.

[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix  SUCCESS
[39.482s]
[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix (Minimal)
SUCCESS [28.979s]
[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix (Full)
FAILURE [4.834s]
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 1:15.916s
[INFO] Finished at: Tue Feb 18 19:48:35 CET 2014
[INFO] Final Memory: 32M/645M
[INFO]

[ERROR] Failed to execute goal
org.apache.karaf.tooling:features-maven-plugin:2.3.5-SNAPSHOT:add-features-to-repo
(add-features-to-repo) on project apache-servicemix-full: Cannot find
version for: org.apache.geronimo.specs/geronimo-jpa_2.0_spec/ -> [Help 1]

I think this is caused by one of pax cdi features referenced by Karaf
enterprise features which includes the geronimo-jpa_2.0_spec bundle with
no version.

  
 pax-cdi-deltaspike-core
mvn:org.ops4j.base/ops4j-base-monitors/1.4.0
mvn:org.ops4j.base/ops4j-base-io/1.4.0
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
*mvn:org.apache.geronimo.specs/geronimo-jpa_2.0_spec/*
 mvn:org.ops4j.pax.jpa/pax-jpa/0.1.1
mvn:org.ops4j.pax.jdbc/pax-jdbc/0.3.0
mvn:org.apache.deltaspike.modules/deltaspike-jpa-module-api/0.5

mvn:org.apache.deltaspike.modules/deltaspike-jpa-module-impl/0.5

mvn:org.ops4j.pax.cdi.fragment/pax-cdi-fragment-ds-jpa/0.6.0

   

I'm writing this mail on this list because I think this feature can
cause problems with other custom distributions based on the Karaf
releases including this features repository.

Regards
Krzysztof




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

Re: [PROPOSAL] Include samples and new dev guide for Karaf 3.0.1

[Krzysztof Sobkowiak]

Hi Jean-Baotiste

I'd like to heslp too with the samples. I'd like to do some work for 
ServiceMix this (and probably next) week. Next I could find some time 
for the samples.


I have another question. You plat to extract the enterprise features 
into a separate subproject. Will be the samples using the enterprise 
features implemented in Karaf or in the subproject?


Regards
Krzysztof

On 18.02.2014 18:16, Jean-Baptiste Onofré wrote:

Hi all,

You probably saw that we did a good job in the quickstart, update 
notes, and user guide for Karaf 3.0.0:

http://karaf.apache.org/manual/latest/quick-start.html
http://karaf.apache.org/manual/latest/update-notes.html
http://karaf.apache.org/manual/latest/users-guide/index.html

I started to work on a complete refactoring of the dev guide on a 
local git branch.
I already started to discussed with Christian to provide dev examples 
directly in the Karaf distribution. It's a refactoring and huge 
extension to the existing demo folder.


The purpose is illustrate the content in the dev guide with "real" 
examples, covering all Karaf features (especially the enterprise ones, 
like JPA, CDI, etc).


I will push the samples module structure.
Christian already said he's in to help, but any help is welcome ;)

I should be able to push the structure and samples frame tonight.

Thanks in advance for your help.

Regards
JB



--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini  | Software Solutions Center 
 | Wroclaw
e-mail: krzys.sobkow...@gmail.com  | 
Twitter: @KSobkowiak

Re: [PROPOSAL] Karaf 3.0.1 and 2.4.0 release schedule

[Jamie G.]

Sounds good to me.

--Jamie

On Tue, Feb 18, 2014 at 11:14 AM, Jean-Baptiste Onofré  
wrote:
> Hi all,
>
> Now that we released Karaf 2.3.4, I would like to propose a schedule for the
> next expected releases:
>
> - Karaf 3.0.1 is a bug fix release on top of 3.0.0. We have one "blocker"
> issue for this release (about the bundle cache corruption with Felix
> Framework 4.2.0), I started to work on it, I will resume tonight. I plan to
> push some changes from my local branches, especially a lot of improvements
> on the maven-karaf-plugin, including new goals.
> I propose to aim 3.0.1 for the first week on March.
> - Karaf 2.4.0 is an upgrade release on top of 2.3.x. It doesn't change some
> much in the Karaf core, but upgrade a lot of dependencies. I plan to review
> the Jira for this release tomorrow.
> I propose to release a first 2.4.0 (on the 2.x branch) just after 3.0.1 (the
> second week of March).
>
> WDYT ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Problem with PAX CDI features in custom distribution

[Krzysztof Sobkowiak]

Hi

I'm trying to upgrade the current code of ServiceMix 5 to Karaf 
3.3.5-SNAPSHOT (2.3.4 fails due to the problem with hibernate-envers 
feature) but I get following error while building the full assembly.


[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix  SUCCESS 
[39.482s]
[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix (Minimal)  
SUCCESS [28.979s]
[INFO] Apache ServiceMix :: Assemblies :: Apache ServiceMix (Full) 
FAILURE [4.834s]
[INFO] 


[INFO] BUILD FAILURE
[INFO] 


[INFO] Total time: 1:15.916s
[INFO] Finished at: Tue Feb 18 19:48:35 CET 2014
[INFO] Final Memory: 32M/645M
[INFO] 

[ERROR] Failed to execute goal 
org.apache.karaf.tooling:features-maven-plugin:2.3.5-SNAPSHOT:add-features-to-repo 
(add-features-to-repo) on project apache-servicemix-full: Cannot find 
version for: org.apache.geronimo.specs/geronimo-jpa_2.0_spec/ -> [Help 1]


I think this is caused by one of pax cdi features referenced by Karaf 
enterprise features which includes the geronimo-jpa_2.0_spec bundle with 
no version.


 

pax-cdi-deltaspike-core
mvn:org.ops4j.base/ops4j-base-monitors/1.4.0
mvn:org.ops4j.base/ops4j-base-io/1.4.0
mvn:org.apache.geronimo.specs/geronimo-jta_1.1_spec/1.1.1
*mvn:org.apache.geronimo.specs/geronimo-jpa_2.0_spec/*
mvn:org.ops4j.pax.jpa/pax-jpa/0.1.1
mvn:org.ops4j.pax.jdbc/pax-jdbc/0.3.0
mvn:org.apache.deltaspike.modules/deltaspike-jpa-module-api/0.5
mvn:org.apache.deltaspike.modules/deltaspike-jpa-module-impl/0.5
mvn:org.ops4j.pax.cdi.fragment/pax-cdi-fragment-ds-jpa/0.6.0
  

I'm writing this mail on this list because I think this feature can 
cause problems with other custom distributions based on the Karaf 
releases including this features repository.


Regards
Krzysztof


--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini  | Software Solutions Center 
 | Wroclaw
e-mail: krzys.sobkow...@gmail.com  | 
Twitter: @KSobkowiak

Re: [PROPOSAL] Include samples and new dev guide for Karaf 3.0.1

[Eric Gong]

Hi, JB

I would like to help, but need to find a good handle so I can contribute to
move along instead of pulling the team back.

Are you coming back to Minneapolis soon?  Or flying through Minneapolis
soon?  Ken and I met, he is a good guy, with part-time MIT program in his
education background.

Eric Gong


On Tue, Feb 18, 2014 at 11:16 AM, Jean-Baptiste Onofré wrote:

> Hi all,
>
> You probably saw that we did a good job in the quickstart, update notes,
> and user guide for Karaf 3.0.0:
> http://karaf.apache.org/manual/latest/quick-start.html
> http://karaf.apache.org/manual/latest/update-notes.html
> http://karaf.apache.org/manual/latest/users-guide/index.html
>
> I started to work on a complete refactoring of the dev guide on a local
> git branch.
> I already started to discussed with Christian to provide dev examples
> directly in the Karaf distribution. It's a refactoring and huge extension
> to the existing demo folder.
>
> The purpose is illustrate the content in the dev guide with "real"
> examples, covering all Karaf features (especially the enterprise ones, like
> JPA, CDI, etc).
>
> I will push the samples module structure.
> Christian already said he's in to help, but any help is welcome ;)
>
> I should be able to push the structure and samples frame tonight.
>
> Thanks in advance for your help.
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

[PROPOSAL] Include samples and new dev guide for Karaf 3.0.1

[Jean-Baptiste Onofré]

Hi all,

You probably saw that we did a good job in the quickstart, update notes, 
and user guide for Karaf 3.0.0:

http://karaf.apache.org/manual/latest/quick-start.html
http://karaf.apache.org/manual/latest/update-notes.html
http://karaf.apache.org/manual/latest/users-guide/index.html

I started to work on a complete refactoring of the dev guide on a local 
git branch.
I already started to discussed with Christian to provide dev examples 
directly in the Karaf distribution. It's a refactoring and huge 
extension to the existing demo folder.


The purpose is illustrate the content in the dev guide with "real" 
examples, covering all Karaf features (especially the enterprise ones, 
like JPA, CDI, etc).


I will push the samples module structure.
Christian already said he's in to help, but any help is welcome ;)

I should be able to push the structure and samples frame tonight.

Thanks in advance for your help.

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

[PROPOSAL] Karaf 3.0.1 and 2.4.0 release schedule

[Jean-Baptiste Onofré]

Hi all,

Now that we released Karaf 2.3.4, I would like to propose a schedule for 
the next expected releases:


- Karaf 3.0.1 is a bug fix release on top of 3.0.0. We have one 
"blocker" issue for this release (about the bundle cache corruption with 
Felix Framework 4.2.0), I started to work on it, I will resume tonight. 
I plan to push some changes from my local branches, especially a lot of 
improvements on the maven-karaf-plugin, including new goals.

I propose to aim 3.0.1 for the first week on March.
- Karaf 2.4.0 is an upgrade release on top of 2.3.x. It doesn't change 
some much in the Karaf core, but upgrade a lot of dependencies. I plan 
to review the Jira for this release tomorrow.
I propose to release a first 2.4.0 (on the 2.x branch) just after 3.0.1 
(the second week of March).


WDYT ?

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

[PROPOSAL] Cellar releases

[Jean-Baptiste Onofré]

Hi all,

I'm updating Cellar master branch to fully support and leverage Karaf 
3.0.0. This branch will also include major change and update (especially 
upgrade to Hazelcast 3.1.0). I worked on a local git branch, I will 
merge and push on master starting from tomorrow night.
I consider releasing Cellar 3.0.0 fully working with Karaf 3.0.x as a 
high priority.
I propose to plan Cellar 3.0.0 for next middle of next week (let say 
Wednesday, February, 23).


On the other hand, some fixes on Cellar master should be merged on 
cellar-2.x branch (working with Karaf 2.x). So, I propose to release 
Cellar 2.3.3 (maintenance release) just after Cellar 3.0.0 (let say end 
of next week).


WDYT ?

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

[INFO] Change in EIK version

[Jean-Baptiste Onofré]

Hi all,

In order to provide EIK version working with Karaf 2.x and 3.x, I 
changed the EIK version policy and branching.
Now, EIK follows the same rule as the other Karaf subprojects (Cellar 
and Cave).


EIK master is now 3.0.0-SNAPSHOT and focus on the Karaf 3.0.0 support.
I gonna create a eik-2.3.x branch (starting with version 2.3.1-SNAPSHOT) 
focus on Karaf 2.3.x support.


I cleaned up a bit the EIK branches: the latest EIK version on each 
branch should work with Eclipse Kepler.


I will deploy a first EIK 2.3.1-SNAPSHOT as soon as the branch is created.

Just after, I will push the changes on master to allow EIK 
3.0.0-SNAPSHOT to work with Karaf 3.0.x. I gonna deploy a SNAPSHOT as well.


It should be done by tonight.

If some users can make a try on the SNAPSHOTs and get back to me, it 
would be great and will allow me to prepare both EIK 2.3.1 and 3.0.0 
release.


Thanks in advance for your help.

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

Re: Problem with hibernate-envers 3.x

[Krzysztof Sobkowiak]

Thanks :-) Sometimes it is easier to solve the problem than open an 
issue for the problem ;-) /

//
//On 18.02.2014 15:19, Jean-Baptiste Onofré wrote://
/

It's fixed on all branches ;)

On 02/18/2014 03:17 PM, Krzysztof Sobkowiak wrote:

Ok. The problem was in 3.x, 2.3.x and 2.x.

Regards
Krzysztof


On 18.02.2014 15:13, Jean-Baptiste Onofré wrote:

No need, it's already done ;)

Regards
JB

On 02/18/2014 03:11 PM, Krzysztof Sobkowiak wrote:

Yes, it is my preferred solution too, I will open proper issue.


On 18.02.2014 15:05, Jean-Baptiste Onofré wrote:

Hi Krzysztof,

it's a mistake in the POM property used for the version and merge.

I would remove hibernate-envers as it doesn't make sense for 
Hibernate

3.x.

Regards
JB

On 02/18/2014 03:01 PM, Krzysztof Sobkowiak wrote:

Hi friends

I think, the hibernate-envers feature for Hibernate 3 should not 
exist

(or must be remastered). There is no
org.hibernate:hibernate-envers:jar:3.3.2.GA anywhere (in central 
repo

nor in JBoss repo).

karaf@root()> feature:install hibernate-envers/3.3.2.GA
Error executing command: Error resolving artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA: Could not find artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA in defaultlocal
(file:/home/kso/.m2/repository/)

The first version of hibernate-envers is 3.5.0, but the original 
jars

from the line 3.x have no OSGi metadata. The line 4.x has been
osgified.
So, we should create a bundle for envers 3.3.2.GA (if doesn't 
exist in
EBR yet) or remove the hibernate-envers feature for this version. 
I'm

going to open an JIRA issue for this problem

Regards
Krzysztof
















--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini  | Software Solutions Center 
 | Wroclaw
e-mail: krzys.sobkow...@gmail.com  | 
Twitter: @KSobkowiak

Re: Problem with hibernate-envers 3.x

[Jean-Baptiste Onofré]

It's fixed on all branches ;)

On 02/18/2014 03:17 PM, Krzysztof Sobkowiak wrote:

Ok. The problem was in 3.x, 2.3.x and 2.x.

Regards
Krzysztof


On 18.02.2014 15:13, Jean-Baptiste Onofré wrote:

No need, it's already done ;)

Regards
JB

On 02/18/2014 03:11 PM, Krzysztof Sobkowiak wrote:

Yes, it is my preferred solution too, I will open proper issue.


On 18.02.2014 15:05, Jean-Baptiste Onofré wrote:

Hi Krzysztof,

it's a mistake in the POM property used for the version and merge.

I would remove hibernate-envers as it doesn't make sense for Hibernate
3.x.

Regards
JB

On 02/18/2014 03:01 PM, Krzysztof Sobkowiak wrote:

Hi friends

I think, the hibernate-envers feature for Hibernate 3 should not exist
(or must be remastered). There is no
org.hibernate:hibernate-envers:jar:3.3.2.GA anywhere (in central repo
nor in JBoss repo).

karaf@root()> feature:install hibernate-envers/3.3.2.GA
Error executing command: Error resolving artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA: Could not find artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA in defaultlocal
(file:/home/kso/.m2/repository/)

The first version of hibernate-envers is 3.5.0, but the original jars
from the line 3.x have no OSGi metadata. The line 4.x has been
osgified.
So, we should create a bundle for envers 3.3.2.GA (if doesn't exist in
EBR yet) or remove the hibernate-envers feature for this version. I'm
going to open an JIRA issue for this problem

Regards
Krzysztof













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

Re: Problem with hibernate-envers 3.x

[Krzysztof Sobkowiak]

Ok. The problem was in 3.x, 2.3.x and 2.x.

Regards
Krzysztof


On 18.02.2014 15:13, Jean-Baptiste Onofré wrote:

No need, it's already done ;)

Regards
JB

On 02/18/2014 03:11 PM, Krzysztof Sobkowiak wrote:

Yes, it is my preferred solution too, I will open proper issue.


On 18.02.2014 15:05, Jean-Baptiste Onofré wrote:

Hi Krzysztof,

it's a mistake in the POM property used for the version and merge.

I would remove hibernate-envers as it doesn't make sense for Hibernate
3.x.

Regards
JB

On 02/18/2014 03:01 PM, Krzysztof Sobkowiak wrote:

Hi friends

I think, the hibernate-envers feature for Hibernate 3 should not exist
(or must be remastered). There is no
org.hibernate:hibernate-envers:jar:3.3.2.GA anywhere (in central repo
nor in JBoss repo).

karaf@root()> feature:install hibernate-envers/3.3.2.GA
Error executing command: Error resolving artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA: Could not find artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA in defaultlocal
(file:/home/kso/.m2/repository/)

The first version of hibernate-envers is 3.5.0, but the original jars
from the line 3.x have no OSGi metadata. The line 4.x has been 
osgified.

So, we should create a bundle for envers 3.3.2.GA (if doesn't exist in
EBR yet) or remove the hibernate-envers feature for this version. I'm
going to open an JIRA issue for this problem

Regards
Krzysztof











--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini  | Software Solutions Center 
 | Wroclaw
e-mail: krzys.sobkow...@gmail.com  | 
Twitter: @KSobkowiak

Re: Problem with hibernate-envers 3.x

[Jean-Baptiste Onofré]

No need, it's already done ;)

Regards
JB

On 02/18/2014 03:11 PM, Krzysztof Sobkowiak wrote:

Yes, it is my preferred solution too, I will open proper issue.


On 18.02.2014 15:05, Jean-Baptiste Onofré wrote:

Hi Krzysztof,

it's a mistake in the POM property used for the version and merge.

I would remove hibernate-envers as it doesn't make sense for Hibernate
3.x.

Regards
JB

On 02/18/2014 03:01 PM, Krzysztof Sobkowiak wrote:

Hi friends

I think, the hibernate-envers feature for Hibernate 3 should not exist
(or must be remastered). There is no
org.hibernate:hibernate-envers:jar:3.3.2.GA anywhere (in central repo
nor in JBoss repo).

karaf@root()> feature:install hibernate-envers/3.3.2.GA
Error executing command: Error resolving artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA: Could not find artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA in defaultlocal
(file:/home/kso/.m2/repository/)

The first version of hibernate-envers is 3.5.0, but the original jars
from the line 3.x have no OSGi metadata. The line 4.x has been osgified.
So, we should create a bundle for envers 3.3.2.GA (if doesn't exist in
EBR yet) or remove the hibernate-envers feature for this version. I'm
going to open an JIRA issue for this problem

Regards
Krzysztof








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

Re: Problem with hibernate-envers 3.x

[Krzysztof Sobkowiak]

Yes, it is my preferred solution too, I will open proper issue.


On 18.02.2014 15:05, Jean-Baptiste Onofré wrote:

Hi Krzysztof,

it's a mistake in the POM property used for the version and merge.

I would remove hibernate-envers as it doesn't make sense for Hibernate 
3.x.


Regards
JB

On 02/18/2014 03:01 PM, Krzysztof Sobkowiak wrote:

Hi friends

I think, the hibernate-envers feature for Hibernate 3 should not exist
(or must be remastered). There is no
org.hibernate:hibernate-envers:jar:3.3.2.GA anywhere (in central repo
nor in JBoss repo).

karaf@root()> feature:install hibernate-envers/3.3.2.GA
Error executing command: Error resolving artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA: Could not find artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA in defaultlocal
(file:/home/kso/.m2/repository/)

The first version of hibernate-envers is 3.5.0, but the original jars
from the line 3.x have no OSGi metadata. The line 4.x has been osgified.
So, we should create a bundle for envers 3.3.2.GA (if doesn't exist in
EBR yet) or remove the hibernate-envers feature for this version. I'm
going to open an JIRA issue for this problem

Regards
Krzysztof






--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini  | Software Solutions Center 
 | Wroclaw
e-mail: krzys.sobkow...@gmail.com  | 
Twitter: @KSobkowiak

Re: Problem with hibernate-envers 3.x

[Jean-Baptiste Onofré]

Hi Krzysztof,

it's a mistake in the POM property used for the version and merge.

I would remove hibernate-envers as it doesn't make sense for Hibernate 3.x.

Regards
JB

On 02/18/2014 03:01 PM, Krzysztof Sobkowiak wrote:

Hi friends

I think, the hibernate-envers feature for Hibernate 3 should not exist
(or must be remastered). There is no
org.hibernate:hibernate-envers:jar:3.3.2.GA anywhere (in central repo
nor in JBoss repo).

karaf@root()> feature:install hibernate-envers/3.3.2.GA
Error executing command: Error resolving artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA: Could not find artifact
org.hibernate:hibernate-envers:jar:3.3.2.GA in defaultlocal
(file:/home/kso/.m2/repository/)

The first version of hibernate-envers is 3.5.0, but the original jars
from the line 3.x have no OSGi metadata. The line 4.x has been osgified.
So, we should create a bundle for envers 3.3.2.GA (if doesn't exist in
EBR yet) or remove the hibernate-envers feature for this version. I'm
going to open an JIRA issue for this problem

Regards
Krzysztof



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

Problem with hibernate-envers 3.x

[Krzysztof Sobkowiak]

Hi friends

I think, the hibernate-envers feature for Hibernate 3 should not exist 
(or must be remastered). There is no 
org.hibernate:hibernate-envers:jar:3.3.2.GA anywhere (in central repo 
nor in JBoss repo).


karaf@root()> feature:install hibernate-envers/3.3.2.GA
Error executing command: Error resolving artifact 
org.hibernate:hibernate-envers:jar:3.3.2.GA: Could not find artifact 
org.hibernate:hibernate-envers:jar:3.3.2.GA in defaultlocal 
(file:/home/kso/.m2/repository/)


The first version of hibernate-envers is 3.5.0, but the original jars 
from the line 3.x have no OSGi metadata. The line 4.x has been osgified. 
So, we should create a bundle for envers 3.3.2.GA (if doesn't exist in 
EBR yet) or remove the hibernate-envers feature for this version. I'm 
going to open an JIRA issue for this problem


Regards
Krzysztof

--
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini  | Software Solutions Center 
 | Wroclaw
e-mail: krzys.sobkow...@gmail.com  | 
Twitter: @KSobkowiak

Re: [DISCUSS] Java DSL for writing commands

[Jean-Baptiste Onofré]

By the way, even without using github, you can use your own branch for 
PoC/prototyping/proposal.


For instance, I do:

git branch my-branch
git checkout my-branch

I work on this branch for new features or bug fixes.
Periodically, I merge from master:

git merge master

When they are no real discussion, I merge back to master and push:

git checkout master
git merge my-branch
git push

But you can also push your branch on wip for discussion (and when it's 
done and the branch merged, we can remove the branch).


github is fine two (it's just two different upstream).

Regards
JB

On 02/18/2014 09:30 AM, Christian Schneider wrote:

Hi Guillaume,

I just looked into your code on github. Btw. I think your choice to use
the github fork and branches to showcase designs is really great. I will
also use this in the future to have a nicely separated environment as a
base for discussion.

In your code you created two new DI annotations @Service and @Reference.
I think we should not go this way. Instead we should leverage the DI
options the framework already provides.
So for blueprint this would be the xml configuration and the blueprint
annotations. The xml configuration would result in what we already have
with the namespace support which is not great but also not too bad. The
blueprint annotations should result in a very similar result like the
one you showcased here. I know blueprint annotations are not really
great but they are what the framework provides and chances are good that
they improve over time.

So for the blueprint annotations I would imagine an action to like like
this:

@Bean(id="selectCommand")
@Command(scope = "db", name = "select", description = "Selects a
datasource")
public class SelectCommand implements Action {
 @Argument(index=0, name="name", required=false,
description="DataSource JNDI name", multiValued=false)
 String name;

 private DbSelect dbSelect;

 @Inject(ref="dbSelect") public void setDbSelect(DbSelect
dbSelect) {
 this.dbSelect = dbSelect;
 }
}

So basically I propose that we simply use the existing annotations. Now
the question is: Could we add handling for our command annotation into
this?

What I would like to have is that we provide some karaf specific
extension that simply gets called for any @Command annotated bean and
that takes the fully injected Action bean and pulishes it using the
blueprint command. Ideally this might even work without a special
namespace handler as we are using regular beans. Unfortunately I do not
know how to implement this. If you can give me some hints how to do it I
am willing to code this of course.

The advantages would be:
- We do not need additional annotations
- We do not need to scan the classpath for annotated classes (ideally
the framework will do this for us)
- We reuse the injection framework and profit from any enhancements that
are done in it
- The user will feel at home as he can use all the features of DI he
already knows.

The special @Reference annotation you proposed has the problem that
users may soon say. It is nice but I want injection by name or injection
by whatever extra feature blueprint might have then. Or they want to
inject config admin properties into the command. So over time we would
recreate portions of a DI framework.

I think a similar method like this might also work for CDI. For CDI I
already implemented a qualifier based auto export for CXF endpoints
which is basically the same problem. The user provides a bean and wants
to use any injections on it. The bean then has to be taken by CXF and
postprocessed in a CXF specific way to export it as an endpoint. Which
is very similar to what we do for Actions.
See
https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-cdi/tasklist-webservice/src/main/java/net/lr/tasklist/webservice/TaskService1.java

There I had to use an additional annotation as I was only able to react
on @Qualifier annotations. Ideally we would also be able to simply react
on @WebService. Unfortunately I did not find out how to do it.

Best regards

Christian


On 17.02.2014 18:29, Guillaume Nodet wrote:

Fwiw, I've implemented the annotation support for blueprint.
See https://github.com/gnodet/karaf/commits/inject
An example for the jms command is at

https://github.com/gnodet/karaf/commit/9f2854da465fb55e57ec01952629e732273786a8


So you're right, that if we want that level of integration for each DI
technology, we'd have to write a layer for each one.  However:
   * I haven't seen many different DI framework used to define commands
   * we still have the solution I proposed in my first draf which is DI
agnostic
   * in the rare cases where none of the above would fit, the user can
still
use the full model (as it was the case previously with SCR), or the java
DSL, which even if it couples a bit the service exposition to karaf,
still
removes lots of the boiler plates for common use cases

Given your experiments do not seem to lead to usable results, and unl

Re: Transitive feature/bundle dependencies

[Ioannis Canellos]

I think that the original intention was not to have the dependency
attribute on jclouds-api-rackspace-cloudidentity. Most probably this
was a side effect of splitting a feature into multiple features.

Of course, the problem that you describe may apply to other cases too.
So, I think that the change you propose makes sense.

Other thoughts?

-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: [ANN] Apache Karaf 2.3.4 Released!

[Henryk Konsek]

> The Karaf team is pleased to announce the release of Karaf version 2.3.4.

Hibernate features! Woohoo!

Thanks guys :) .

-- 
Henryk Konsek
http://henryk-konsek.blogspot.com

Transitive feature/bundle dependencies

[Grzegorz Grzybek]

Hello

I have such case:

feature one:


jclouds-api-openstack-cinder
jclouds-api-rackspace-cloudidentity

mvn:org.apache.jclouds.provider/rackspace-cloudblockstorage-us/1.6.2-incubating


which depends on feature two:


jclouds-compute
jclouds-api-openstack-keystone
mvn:org.apache.jclouds.api/rackspace-cloudidentity/1.6.2-incubating


the problem is that when I install feature one, then:
 - when it comes to installing "jclouds-api-rackspace-cloudidentity",
bundle "rackspace-cloudidentity" isn't installed because the feature has
@resolver set and the bundle is dependency="true"
 - when it returns to installing "jclouds-rackspace-cloudblockstorage-us",
the feature isn't correctly resolved because it's bundle
"rackspace-cloudblockstorage-us" requires (by package) bundle
"rackspace-cloudidentity"

I think that the dependency="true" bundles should be available "up the
chain", so the bundles from "upper features" are correctly resolved.

This should be easy to propagate these dependencies... Any problems? I
could provide a patch.

regards
Grzegorz Grzybek

Re: [DISCUSS] Java DSL for writing commands

[Christian Schneider]

Hi Guillaume,

I just looked into your code on github. Btw. I think your choice to use 
the github fork and branches to showcase designs is really great. I will 
also use this in the future to have a nicely separated environment as a 
base for discussion.


In your code you created two new DI annotations @Service and @Reference. 
I think we should not go this way. Instead we should leverage the DI 
options the framework already provides.
So for blueprint this would be the xml configuration and the blueprint 
annotations. The xml configuration would result in what we already have 
with the namespace support which is not great but also not too bad. The 
blueprint annotations should result in a very similar result like the 
one you showcased here. I know blueprint annotations are not really 
great but they are what the framework provides and chances are good that 
they improve over time.


So for the blueprint annotations I would imagine an action to like like 
this:


@Bean(id="selectCommand")
@Command(scope = "db", name = "select", description = "Selects a datasource")
public class SelectCommand implements Action {
@Argument(index=0, name="name", required=false, description="DataSource JNDI 
name", multiValued=false)
String name;

private DbSelect dbSelect;

@Inject(ref="dbSelect")  
public void setDbSelect(DbSelect dbSelect) {

this.dbSelect = dbSelect;
}
}

So basically I propose that we simply use the existing annotations. Now 
the question is: Could we add handling for our command annotation into this?


What I would like to have is that we provide some karaf specific 
extension that simply gets called for any @Command annotated bean and 
that takes the fully injected Action bean and pulishes it using the 
blueprint command. Ideally this might even work without a special 
namespace handler as we are using regular beans. Unfortunately I do not 
know how to implement this. If you can give me some hints how to do it I 
am willing to code this of course.


The advantages would be:
- We do not need additional annotations
- We do not need to scan the classpath for annotated classes (ideally 
the framework will do this for us)
- We reuse the injection framework and profit from any enhancements that 
are done in it
- The user will feel at home as he can use all the features of DI he 
already knows.


The special @Reference annotation you proposed has the problem that 
users may soon say. It is nice but I want injection by name or injection 
by whatever extra feature blueprint might have then. Or they want to 
inject config admin properties into the command. So over time we would 
recreate portions of a DI framework.


I think a similar method like this might also work for CDI. For CDI I 
already implemented a qualifier based auto export for CXF endpoints 
which is basically the same problem. The user provides a bean and wants 
to use any injections on it. The bean then has to be taken by CXF and 
postprocessed in a CXF specific way to export it as an endpoint. Which 
is very similar to what we do for Actions.
See 
https://github.com/cschneider/Karaf-Tutorial/blob/master/tasklist-cdi/tasklist-webservice/src/main/java/net/lr/tasklist/webservice/TaskService1.java
There I had to use an additional annotation as I was only able to react 
on @Qualifier annotations. Ideally we would also be able to simply react 
on @WebService. Unfortunately I did not find out how to do it.


Best regards

Christian


On 17.02.2014 18:29, Guillaume Nodet wrote:

Fwiw, I've implemented the annotation support for blueprint.
See https://github.com/gnodet/karaf/commits/inject
An example for the jms command is at

https://github.com/gnodet/karaf/commit/9f2854da465fb55e57ec01952629e732273786a8

So you're right, that if we want that level of integration for each DI
technology, we'd have to write a layer for each one.  However:
   * I haven't seen many different DI framework used to define commands
   * we still have the solution I proposed in my first draf which is DI
agnostic
   * in the rare cases where none of the above would fit, the user can still
use the full model (as it was the case previously with SCR), or the java
DSL, which even if it couples a bit the service exposition to karaf, still
removes lots of the boiler plates for common use cases

Given your experiments do not seem to lead to usable results, and unless
someone objects, I'll go ahead and commit what I have.




--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com