from:"Christoph Gritschenberger"

Re: javax.annotation 1.2.0 and KARAF-2660

2016-02-16 Thread Christoph Gritschenberger

Nope. just missed it, I guess

regards,
Christoph

On 2016-02-12 09:17, jochenw wrote:
> Hi,
> 
> we just stumbled over that topic again. In Karaf 4.0.x, javax.annotation
> version in jre.properties are set to 1.0 - fine. However, in the default
> config.properties, the javax.annotation packages are added to
> org.osgi.framework.system.packages.extra with version 1.2. If a bundle wants
> to use the JEE version, e.g. from javax.annotation-api, it still finds the
> standard versions, leading e.g. to 
> 
> Caused by: java.lang.ClassNotFoundException: javax.annotation.Priority
> 
> When switching the versions in config.properties to 1.0, it works.
> 
> Is there a reason to have the 1.2 versions in the
> org.osgi.framework.system.packages.extra, differing from what is used in
> jre.properties?
> 
> Regards,
> Jochen
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/javax-annotation-1-2-0-and-KARAF-2660-tp4036056p4045303.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>

Re: [VOTE] Release Apache Karaf 3.0.3

2015-01-28 Thread Christoph Gritschenberger

+1 (non-binding)

kind regards,
Christoph

On 28/01/15 02:01, Jamie G. wrote:
> Hi,
> 
> We resolved 97 issues in this release:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.3-release.page?view=markup
> 
> Dependency changes can be reviewed here:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1021/
> 
> Git tag:
> karaf-3.0.3
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
>

Re: karaf git commit: Revert "[KARAF-2660] adjust javax.annotation-versions to reflect those in Java SE"

2014-11-27 Thread Christoph Gritschenberger

Hi,

As I explained in KARAF-3329 [1] (sorry for the wrong issue-reference in
the commit-message) Java SE only provides 1.0-classes

I just listed the contents of javax.annotation in openjdk-8 and
oracle-jdk-8 (SE)

➜ /tmp/rt » tree javax/annotation
javax/annotation
├── Generated.class
├── PostConstruct.class
├── PreDestroy.class
├── Resource$AuthenticationType.class
├── Resource.class
└── Resources.class

ManagedBean (since 1.1) and Priority (since 1.2) are missing.

As for javax.annotation.processing, the javadoc [2] says since 1.6,
which in this case is the java-version. So yes, we propably should
remove the version here entirely.

kind regards
Christoph

[1] https://issues.apache.org/jira/browse/KARAF-3329
[2]
http://docs.oracle.com/javase/8/docs/api/javax/annotation/processing/Completion.html

On 27/11/14 13:39, Guillaume Nodet wrote:
> That's only partially right.  What is missing is packages, not classes in
> the packages.
> I think the javax.annotation package is really on par with jsr250 1.1,
> however some packages like javax.annotation.security and
> javax.annotation.sql aren't provided by the JRE, but that does not affect
> the version of the javax.annotation package itself.
> 
> 2014-11-27 13:25 GMT+01:00 Achim Nierbeck :
> 
>> Hi,
>>
>> I'm not saying we should keep 1.6 (a rather high version) though,
>> I'm not sure that 1.1 is actually right either.
>> We had user-feedback that the jdk version didn't contain specific classes
>> of the 1.1 Version.
>> But I can't remember the issue number and I currently am busy so I can't
>> search this up again.
>> We need to make sure we don't show up with the wrong version number.
>>
>> @Christoph, I thought you had an issue for this. Could you please point us
>> into that direction?
>>
>>
>> regards, Achim
>>
>> 2014-11-27 11:55 GMT+01:00 Guillaume Nodet :
>>
>>> For the 1.1 version on javax.annotation,  it seems to me that jsr250 1.1
>>> from 2009 [1] includes several code changes, such as the lookup attribute
>>> on @Resource, which seems to be present in idk 1.7
>>>
>>> [1]
>>>
>>>
>> https://jcp.org/aboutJava/communityprocess/maintenance/jsr250/jsr250ChangeLog.html
>>>
>>>
>>> 2014-11-27 11:26 GMT+01:00 Jean-Baptiste Onofré :
>>>
>>>> Hi,
>>>>
>>>> Guillaume has some issue to send e-mails on the mailing list.
>>>>
>>>> He explained why he reverted this change on IRC:
>>>>
>>>>  anyway, so i htink javax.annotation should actually be 1.1,
>> and
>>>> remove the 1.6 and the javax.annotation.processing
>>>>  1.1 is the correct jsr250 revision used in jdk 7 and 8, and
>> 1.0
>>>> for jdk 6 (which we don’t really support anymore btw)
>>>>  gnodet: like we had before, AFAIR, Christoph did the
>> change, I
>>>> don't remember exactly why
>>>>  gnodet: anyway, the change affects PAX CDI
>>>>  well, we had 1.2 for jdk8 which is wrong
>>>>  gnodet: ok
>>>>  that’s because pax cdi requires 1.1, which is fine to me
>>>>  and that’s the one in the jre afaik
>>>>  gnodet: it sounds good
>>>>  the 1.6 on javax.annotation.processing is wrong too, as it
>> comes
>>>> from nowhere (well, actually i suppose it’s because it has been
>>> introduced
>>>> in java 6)
>>>>  gnodet: ok
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 11/27/2014 08:47 AM, Achim Nierbeck wrote:
>>>>
>>>>> Well fixing the build by adding wrong versions is wrong
>>>>>
>>>>> I'm -1 for this revert.
>>>>>
>>>>> We have  to find a better  way to fix this.
>>>>>
>>>>> sent from mobile device
>>>>> Am 27.11.2014 03:02 schrieb "Jean-Baptiste Onofré" :
>>>>>
>>>>>  Yes, it fixes the build, and I also reverted the felix gogo runtime
>>> 0.14
>>>>>> update which break the ssh itest.
>>>>>>
>>>>>> We should have a clean build soon.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 11/26/2014 11:53 PM, Christoph Gritschenberger wrote:
>>>>>>
>>>>>>  It's breaking the build. I submitted a pull-request to pax-cdi to
>>>>>>> include the missing libraries, but Harald initially disagreed

Re: karaf git commit: Revert "[KARAF-2660] adjust javax.annotation-versions to reflect those in Java SE"

2014-11-26 Thread Christoph Gritschenberger

It's breaking the build. I submitted a pull-request to pax-cdi to
include the missing libraries, but Harald initially disagreed with
including 1.2-specs because only 1.1 is required. Haven't heard back
yet. I poked again today.

On 3.x, I included 1.2-annotations in the feature that is provided in
karaf. But on master, many features depend on this, and it seemed more
appropriate to tackle this directly in pax-cdi.

kind regards,
Christoph

On 26/11/14 16:40, Achim Nierbeck wrote:
> Why did you revert this?
> afaik the annotation version included in the JDK is 1.0 so it's actually
> missing classes if it's set to 1.1 so that is just wrong.
> 
> regards, Achim
> 
> 2014-11-26 16:11 GMT+01:00 :
> 
>> Repository: karaf
>> Updated Branches:
>>   refs/heads/master dc512d620 -> 1e21be1b9
>>
>>
>> Revert "[KARAF-2660] adjust javax.annotation-versions to reflect those in
>> Java SE"
>>
>> This reverts commit b11ed61ff9a06fc6e0480869184d0eca33ad1cce.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/karaf/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/karaf/commit/1e21be1b
>> Tree: http://git-wip-us.apache.org/repos/asf/karaf/tree/1e21be1b
>> Diff: http://git-wip-us.apache.org/repos/asf/karaf/diff/1e21be1b
>>
>> Branch: refs/heads/master
>> Commit: 1e21be1b9dd69dbfee78d3367521ffd90161db60
>> Parents: dc512d6
>> Author: Guillaume Nodet 
>> Authored: Wed Nov 26 16:10:19 2014 +0100
>> Committer: Guillaume Nodet 
>> Committed: Wed Nov 26 16:10:33 2014 +0100
>>
>> --
>>  .../filtered-resources/resources/etc/jre.properties | 12 ++--
>>  1 file changed, 6 insertions(+), 6 deletions(-)
>> --
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/karaf/blob/1e21be1b/assemblies/features/framework/src/main/filtered-resources/resources/etc/jre.properties
>> --
>> diff --git
>> a/assemblies/features/framework/src/main/filtered-resources/resources/etc/jre.properties
>> b/assemblies/features/framework/src/main/filtered-resources/resources/etc/jre.properties
>> index fd48ccb..94da9db 100644
>> ---
>> a/assemblies/features/framework/src/main/filtered-resources/resources/etc/jre.properties
>> +++
>> b/assemblies/features/framework/src/main/filtered-resources/resources/etc/jre.properties
>> @@ -27,8 +27,8 @@ jre-1.6= \
>>   javax.accessibility, \
>>   javax.activation;version="1.1", \
>>   javax.activity, \
>> - javax.annotation;version="1.0", \
>> - javax.annotation.processing;version="1.6", \
>> + javax.annotation;version="1.1", \
>> + javax.annotation.processing;version="1.1", \
>>   javax.crypto, \
>>   javax.crypto.interfaces, \
>>   javax.crypto.spec, \
>> @@ -190,8 +190,8 @@ jre-1.7= \
>>   javax.accessibility, \
>>   javax.activation;version="1.1", \
>>   javax.activity, \
>> - javax.annotation;version="1.0", \
>> - javax.annotation.processing;version="1.6", \
>> + javax.annotation;version="1.1", \
>> + javax.annotation.processing;version="1.1", \
>>   javax.crypto, \
>>   javax.crypto.interfaces, \
>>   javax.crypto.spec, \
>> @@ -351,8 +351,8 @@ jre-1.8= \
>>   javax.accessibility, \
>>   javax.activation;version="1.1", \
>>   javax.activity, \
>> - javax.annotation;version="1.0", \
>> - javax.annotation.processing;version="1.6", \
>> + javax.annotation;version="1.2", \
>> + javax.annotation.processing;version="1.2", \
>>   javax.crypto, \
>>   javax.crypto.interfaces, \
>>   javax.crypto.spec, \
>>
>>
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [INFO] itests failure on master

2014-10-29 Thread Christoph Gritschenberger

The CdiFeature-tests are my fault, I'm working on a fix for pax-cdi.

kind regards,
Christoph

On 29/10/14 19:44, Jean-Baptiste Onofré wrote:
> Hi all,
> 
> I'm just back from vacation.
> 
> I tried to build master with the latest changes, and lot of itests failed.
> 
> I will fix most of them tonight and tomorrow morning (and identify the
> changes causing the troubles).
> 
> Regards
> JB




smime.p7s
Description: S/MIME Cryptographic Signature

Re: javax.annotation 1.2.0 and KARAF-2660

2014-10-28 Thread Christoph Gritschenberger


Hi,

Well this actually has been an issue since karaf-3.0.0. That's when it 
started exporting javax.annotation. At first it was exported with 
version "1.1" before it was changed it to "1.2" in karaf-3.0.2.


As soon as a client-bundle actually requires a 1.1 or 1.2 annotation and 
the javax.annotation-bundle has to be provided this is an issue.


AFAICT there aren't that many javax-specs affected with such a version 
descrepancy. Putting it in endorsed, doesn't sound too bad, and would 
work around issues with multiple javax.annotation-bundles present.


kind regards,
Christoph


On 28/10/14 14:39, Daniel Kulp wrote:

Curiosity question….

CXF imports javax.annotation using a version range of [0.0,2) so it should work 
with a different versions.

If I install CXF, how will this work with the various versions now provided?  
In particular, if a user bundle providing a CXF service uses the 
javax.annotation things, is there an easy way to make sure both CXF and the 
user bundle end up using the same version?   For example, if I install CXF 
first, I assume it would get 1.0 from the JRE.   Then I install a the 1.2 
bundle, then a user bundle.   Would the user bundle get 1.2 and then not 
properly work with CXF?   If I restart the container, would CXF then pick up 
1.2?   This is beginning to look very complicated and very non-obvious error 
inducing.

I’m almost wondering if it makes more sense to throw 1.2 into endorsed and make 
sure that’s exported from jre.properties as 1.2.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: git commit: [KARAF-3329] provide javax.annotation-1.2 via extra bundle

2014-10-28 Thread Christoph Gritschenberger

Hi,

1) in 3.0.x it is afaict. In master there are more features depending on
it (investigating which ones right now).

2) Well, I'm not sure. After all this dependency is optional for Java EE
environments. Let's see what other features need this.

kind regards,
Christoph

On 28/10/14 10:57, Achim Nierbeck wrote:
> Hi,
> 
> got two questions regarding this:
> 
> - Are you sure this is the only place where this bundle is needed?
> - wouldn't it be a better fit to place this dependency to pax-cdi-weld?
> 
> regards, Achim
> 
> 
> 2014-10-28 10:46 GMT+01:00 :
> 
>> Repository: karaf
>> Updated Branches:
>>   refs/heads/karaf-3.0.x 20764a594 -> ee3d7e982
>>
>>
>> [KARAF-3329] provide javax.annotation-1.2 via extra bundle
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/karaf/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/karaf/commit/ee3d7e98
>> Tree: http://git-wip-us.apache.org/repos/asf/karaf/tree/ee3d7e98
>> Diff: http://git-wip-us.apache.org/repos/asf/karaf/diff/ee3d7e98
>>
>> Branch: refs/heads/karaf-3.0.x
>> Commit: ee3d7e982200d846de68e5f35807cf398533af13
>> Parents: 20764a5
>> Author: Christoph Gritschenberger 
>> Authored: Tue Oct 28 10:45:48 2014 +0100
>> Committer: Christoph Gritschenberger 
>> Committed: Tue Oct 28 10:45:48 2014 +0100
>>
>> --
>>  assemblies/features/enterprise/src/main/feature/feature.xml | 1 +
>>  1 file changed, 1 insertion(+)
>> --
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/karaf/blob/ee3d7e98/assemblies/features/enterprise/src/main/feature/feature.xml
>> --
>> diff --git a/assemblies/features/enterprise/src/main/feature/feature.xml
>> b/assemblies/features/enterprise/src/main/feature/feature.xml
>> index 6d23cc4..c76515e 100644
>> --- a/assemblies/features/enterprise/src/main/feature/feature.xml
>> +++ b/assemblies/features/enterprise/src/main/feature/feature.xml
>> @@ -253,6 +253,7 @@
>>  > version="${weld.version}" resolver="(obr)">
>>  Add support of JBoss Weld CDI container.
>>  pax-cdi-weld
>> +mvn:javax.annotation/javax.annotation-api/1.2
>>
>>  mvn:org.jboss.weld/weld-osgi-bundle/${weld.version}
>>  
>>
>>
>>
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: javax.annotation 1.2.0 and KARAF-2660

2014-10-27 Thread Christoph Gritschenberger

Actually all Java SE versions lack the "java.annotation.ManagedBean"
that was added in 1.1.

I now changed the versions to 1.0 for JRE 6, 7, and 8.

I applied the fix to master and karaf-3.0.x

kind regards,
Christoph

On 23/10/14 11:56, jsnharris wrote:
> I changed the javax.annotation version in the etc/jre.properties to 1.1 and
> then added the javax.annotation 1.2 bundle to my Karaf installation and the
> annotation I need is accessed correctly. If the 1.1 versions are still
> available for other bundles to use and as 1.1 is in SE, this would appear to
> be the correct way forward (assuming EE versions are not to be part of
> standard JRE Karaf settings) 
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/javax-annotation-1-2-0-and-KARAF-2660-tp4036056p4036090.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: javax.annotation 1.2.0 and KARAF-2660

2014-10-22 Thread Christoph Gritschenberger

Hi,

I created KARAF-3329 [1] I have the commit local here, but didn't want
to commit it right away because it "breaks" KARAF-2660 [2].

I wasn't quite sure whether Java SE or Java EE is considered the primary
target environment.

I'm all for Java SE as a primary target

kind regards,
Christoph

[1] https://issues.apache.org/jira/browse/KARAF-3329
[2] https://issues.apache.org/jira/browse/KARAF-2660

On 22/10/14 22:18, Achim Nierbeck wrote:
> Hi,
> 
> in that case plz. open a Jira Issue so we make sure the version in the
> jre.properties is corrected to 1.0.
> 
> If a newer version is needed it's usually best to provide that bundle with
> the "custome" code/bundles.
> 
> regards, Achim
> 
> 2014-10-21 22:15 GMT+02:00 Christoph Gritschenberger <
> christoph.gritschenber...@gmail.com>:
> 
>> I recently discovered an "oddity", with javax.annotation.
>>
>> The problem afaics is that Java 6/7/8 SE all only contain the 1.0-specs
>> of javax.annotation whereas Java EE contains 1.1/1.2 (don't know exactly
>> which versions contain what).
>>
>> I'm not sure Java EE should be the reference for package-versions in
>> jre.properties
>>
>> kind regards
>> Christoph
>>
>> On 21/10/14 21:25, jsnharris wrote:
>>> Although the javax.annotation version is fixed in Karaf 3.0.1, the new
>>> annotations in 1.2.0 (e.g. javax.annotation.Priority) are still not
>>> available to Karaf out of the box. Is the solution really a case of
>>> commenting out the javax.annotation entry in the jre 7 part of
>>> etc/jre.properties and then including the 1.2 javax.annotation bundle as
>> a
>>> feature or should the latest bundle be included as part of the karaf
>>> distribution?
>>>
>>>
>>>
>>> --
>>> View this message in context:
>> http://karaf.922171.n3.nabble.com/javax-annotation-1-2-0-and-KARAF-2660-tp4036056.html
>>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>>
>>
>>
>>
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: javax.annotation 1.2.0 and KARAF-2660

2014-10-21 Thread Christoph Gritschenberger

I recently discovered an "oddity", with javax.annotation.

The problem afaics is that Java 6/7/8 SE all only contain the 1.0-specs
of javax.annotation whereas Java EE contains 1.1/1.2 (don't know exactly
which versions contain what).

I'm not sure Java EE should be the reference for package-versions in
jre.properties

kind regards
Christoph

On 21/10/14 21:25, jsnharris wrote:
> Although the javax.annotation version is fixed in Karaf 3.0.1, the new
> annotations in 1.2.0 (e.g. javax.annotation.Priority) are still not
> available to Karaf out of the box. Is the solution really a case of
> commenting out the javax.annotation entry in the jre 7 part of
> etc/jre.properties and then including the 1.2 javax.annotation bundle as a
> feature or should the latest bundle be included as part of the karaf
> distribution? 
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/javax-annotation-1-2-0-and-KARAF-2660-tp4036056.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Reset Karaf cache directory

2014-09-25 Thread Christoph Gritschenberger

Hi,

You can also put the following line into your etc/system.properties

karaf.clean.cache=false

If you want to trigger a cache-clean from within your application, just
create a file named "clean_cache" in data-directory
(System.getProperty("karaf.data"))

kind regards,
Christoph

On 25/09/14 15:47, Jean-Baptiste Onofré wrote:
> Hi
> 
> Why do you delete at each start ?
> 
> You can use: bin/karaf clean or bin/karaf clean-all to cleanup the cache
> at startup.
> 
> Regards
> JB
> 
> On 09/25/2014 03:28 PM, rcbandit wrote:
>> Hi, I'm interested how I can reset cache directory. Every time when I
>> start
>> Karaf I have to delete manually cache directory.
>>
>>
>>
>> -- 
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Reset-Karaf-cache-directory-tp4035519.html
>>
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Karaf does not startup on Windows 7

2014-07-01 Thread Christoph Gritschenberger

Is your application tied to this exact java-version or can you try at
least a more recent version of Java6 [1]?

[1]
http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html

On 01/07/14 10:42, SapnaB wrote:
> Hi Christoph,
> 
> Im using JDK 1.6. JAVA_HOME is set to : C:\Program Files\Java\jdk1.6.0_24
> 
> Regards,
> Sapna
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Karaf-does-not-startup-on-Windows-7-tp4033876p4033902.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Karaf does not startup on Windows 7

2014-07-01 Thread Christoph Gritschenberger

Can you tell us which java-version you are using?
Is JAVA_HOME set?

kind regards,
Christoph

On 30/06/14 19:50, SapnaB wrote:
> Hi JB,
> 
> Yes, thats how I start the Karaf instance. Both versions(2.3.2, 3.0.1) work
> fine in linux, but im unable to get them working in Windows 7.
> 
> Thanks,
> Sapna
> 
> 
> 
> --
> View this message in context: 
> http://karaf.922171.n3.nabble.com/Karaf-does-not-startup-on-Windows-7-tp4033876p4033880.html
> Sent from the Karaf - Dev mailing list archive at Nabble.com.
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Apache Karaf 3.0.1

2014-04-11 Thread Christoph Gritschenberger

+1

kind regards,
Christoph

On 10/04/14 23:57, Jamie G. wrote:
> Hi,
> 
> We resolved 145 issues in this release:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.1-release.page?view=markup
> 
> Dependency changes can be reviewed here:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
>  (The website published table will be updated after vote)
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1005/
> 
> Git tag:
> karaf-3.0.1
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] karaf-maven-plugin changes

2014-03-04 Thread Christoph Gritschenberger

I think it's a bad idea to _rename_ plugin-goals. That would break 
compatibility with 3.0-plugin-configurations.


Maybe the new names should be provided as aliases and the old names 
removed in 4.0


kind regards,
christoph

On 04/03/14 20:27, Jean-Baptiste Onofré wrote:

The refactoring is on master (3.1.x), I don't change on 3.0.x as it's a
maintenance branch now.

Regards
JB

On 03/04/2014 07:48 PM, Jamie G. wrote:

1a. Refactoring/Renaming goals - on the 3.0.x or for 3.1.x? The
shorter names are good, just want a clarification on target.

1b. New Goals - Sounds good.

2. New tests are always welcome :)

On Tue, Mar 4, 2014 at 3:09 PM, Jean-Baptiste Onofré 
wrote:

Hi all,

I would like to discuss with you about my current work on the
karaf-maven-plugin:

1/ on master, I refactored the karaf-maven-plugin to use the Maven
annotations. It's simpler and cleaner, and compatible with all Maven
version. I also added the Maven 3.1 and 3.2 support. I also fixed the
same
issue as on karaf-3.0.x (see below) and cleanup the code (using global
I propose the following cleanup/refactoring/renaming on the goals:
- karaf:commands-generate-help renamed to karaf:commands-documentation
- karaf:create-instance-archive renamed to karaf:instance-archive
- karaf:features-add-to-repository renamed to karaf:populate-repository
- karaf:features-create-kar renamed to karaf:create-kar
- karaf:features-export-meta-data renamed to karaf:export-metadata
- karaf:features-generate-descriptor renames to karaf:create-features
- karaf:features-validate-descriptor renamed to karaf:validate-features
Introduction of new goals:
- karaf:client to interact with a running instance
- karaf:instance to interact with instances (start, stop, etc)
- karaf:deploy to deploy bundles or features (and eventually populate
the
system repository using scp)
- karaf:run to bootstrap and run a Karaf container
I also merged the scr-karaf-maven-plugin in karaf-maven-plugin as a
dedicated goal (karaf:scr).
2/ on karaf-3.0.x branch, I introduced a set of new integration tests
(using
the maven-invoker-plugin). I fixed the different issues (construct
global
features set to resolve all features including transitive ones,
support of
file and http URLs, support of  in features repository XML,
etc).

Thoughts ?

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







smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Apache Karaf version 3.0.0

2013-12-21 Thread Christoph Gritschenberger


OK maybe this issue's got something to do with my environment.
Cannot reproduce it anymore

Just downloaded the source-archive into a fresh ubuntu-vm and ran the 
build successfully,


so changing my vote to +1 (non-binding)

kind regards,
Christoph

On 2013-12-21 21:07, Christoph Gritschenberger wrote:

Sorry for being a bit of a grinch here:

-1, because an itest fails

Results :

Tests in error:
   testJMXSecurityAsAdmin(org.apache.karaf.itests.JMXSecurityTest):
Configuration org.apache.karaf.service.acl.command.1387655750210_36.x
deleted

Tests run: 93, Failures: 0, Errors: 1, Skipped: 2

I was able to reproduce it on fresh installs (the second build went OK
on both systems I tested this on).

I'll investigate the test-failure further later this evening.

kind regards,
christoph


On 2013-12-21 18:40, Jamie G. wrote:

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup


Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup

(The website published table will be updated after vote)

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

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Apache Karaf version 3.0.0

2013-12-21 Thread Christoph Gritschenberger


Sorry for being a bit of a grinch here:

-1, because an itest fails

Results :

Tests in error:
  testJMXSecurityAsAdmin(org.apache.karaf.itests.JMXSecurityTest): 
Configuration org.apache.karaf.service.acl.command.1387655750210_36.x 
deleted


Tests run: 93, Failures: 0, Errors: 1, Skipped: 2

I was able to reproduce it on fresh installs (the second build went OK 
on both systems I tested this on).


I'll investigate the test-failure further later this evening.

kind regards,
christoph


On 2013-12-21 18:40, Jamie G. wrote:

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup

Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
(The website published table will be updated after vote)

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

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.





  




http://java.oracle.com/"/>

















































http://bugreport.sun.com/bugreport/"/>





  
  
  
  
  
javax.management.MBeanException: Configuration org.apache.karaf.service.acl.command.1387655750210_36.x deleted
	at org.apache.karaf.config.core.impl.ConfigMBeanImpl.getConfigs(ConfigMBeanImpl.java:75)
	at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
	at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
	at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
	at javax.management.StandardMBean.getAttribute(StandardMBean.java:372)
	at Proxy8161bf25_7a09_4f5b_bbb3_1dafd4742bc8.getAttribute(Unknown Source)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
	at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.apache.karaf.management.boot.KarafMBeanServerBuilder$MBeanInvocationHandler.invoke(KarafMBeanServerBuilder.java:66)
	at com.sun.proxy.$Proxy14.getAttribute(Unknown Source)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
	at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:657)
	at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
	at sun.rmi.transport.Transport$1.run(Transport.java:177)
	at sun.rmi.transport.Transport$1.run(Transport.java:174)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(

Re: Support Assembly protocol

2013-06-30 Thread Christoph Gritschenberger


Have you tried the "bundle:watch" command?

Assuming your project constists of multiple bundles, you can just 
rebuild a single bundle (via mvn install). and karaf will automatically 
pickup the new SNAPSHOT-version from your local .m2.


I'm not sure how well that works with wars (I remember having issues 
back when we used to rely on wars).


kind regards,
christoph


On 2013-06-30 15:37, nseb wrote:

for example:

spring-tx
jpa  
transaction  
jndi

assembly:file:///D:\\Projects\\JeetConsulting\\jeet-core\\Sources\\jeet-core\\jeet-core-api\\target\\classes
   

it helps to have when we develop have a hot redeployment, without rebuilding
a war.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Support-Assembly-protocol-tp4029163p4029165.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Switch from svn to git

2013-06-25 Thread Christoph Gritschenberger


+1
for reasons already stated

kind regards,
christoph

On 2013-06-25 13:31, Jamie G. wrote:

+1

For clarification - all our generated artifacts will be signed, and a tag
of our release created such that anyone could reproduce our release.

The actual commit transaction to SCM is the only part that does not have a
signature.

As to the snapshots appearing in poms, Central Nexus will not allow us to
release if it detects them during a promote - I do not believe however this
is related to SCM, that's probably a configuration issue of the release
plugin.

Our release procedures and release check signatures scripts will need to be
verified post change.

-Jamie


On Tue, Jun 25, 2013 at 8:30 AM, Łukasz Dywicki  wrote:


+1 from me

Switching to git will let us process pull requests in easier way. Maven is
not afraid of git as well.

I'm not scared by Camel issues with git since they have more modules than
they need. ;-)

Cheers,
Lukasz

Wiadomość napisana przez Achim Nierbeck  w dniu
25 cze 2013, o godz. 11:54:


Hi,

I'm
-1 for this due to the things that popped up with the latest Camel

release.

[1]
Even though I do not fully understand why this is an issue, cause when
releasing OPS4j artefacts we never had such issues.

If this issues is cleared I'd go for +1

regards, Achim


[1] -


http://camel.465427.n5.nabble.com/VOTE-Release-Apache-Camel-2-10-5-tp5734607p5734684.html



2013/6/25 Andreas Pieber 


hey, there is no 0 option :-)

still +1 for the switch. Would make forking and experimenting (and
especially getting the changes back) so much easier...

Kind regards,
Andreas


On Tue, Jun 25, 2013 at 11:12 AM, Jean-Baptiste Onofré 
wrote:



Hi all,

to follow the discussion that we had some weeks ago, I start here a

formal

vote to migrate our scm from svn to git.

Please vote to approve this switch:

[ ] +1 Approve the switch (from svn to git)
[ ] -1 Do not approve the switch (please provide specific comments)

This vote will be open for 72 hours.

Thanks,
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 










smime.p7s
Description: S/MIME Cryptographic Signature

Re: Remote Debugging of Karaf

2013-03-17 Thread Christoph Gritschenberger


It is configured in the startup-script,

DEFAULT_JAVA_DEBUG_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE 
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005"



You an override these by setting the JAVA_DEBUG_OPTS-environment variable

regards,
christoph

On 2013-03-17 05:32, Abhinav Mishra wrote:

Thanks a ton for response .

Which configuration file have this port - 5005 configured ?

Thanks,
Abhinav



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Remote-Debugging-of-Karaf-tp4028192p4028230.html
Sent from the Karaf - Dev mailing list archive at Nabble.com.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

2013-03-13 Thread Christoph Gritschenberger


+1

kind regards,
christoph

On 2013-03-12 04:26, Jamie G. wrote:

Hi,

We resolved 964 issues in this release (web page will be published
post RC promotion):
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0.RC1-release.page

NOTE: This is a technology preview release candidate.

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

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Karaf version 2.3.1

2013-03-03 Thread Christoph Gritschenberger


+1

regards,
christoph

On 2013-03-01 02:23, Jamie G. wrote:

Hi,

We resolved 99 issues in this release (web page will be published post
RC promotion):
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-2.3.1-release.page

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

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-2.3.1/

2.3.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-2.3.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Board report for March, 2013

2013-02-28 Thread Christoph Gritschenberger


+1

regards,
christoph

On 2013-03-01 08:02, fbalicchia wrote:

+1

2013/2/28 Achim Nierbeck 


Looks good to me.
+1

Regards, Achim

sent from mobile device
Am 28.02.2013 21:08 schrieb "Jamie G." :


+1 looks good.

On Thu, Feb 28, 2013 at 4:22 PM, Andreas Pieber 
wrote:

+1 kind regards, Andreas
On 28 Feb 2013 19:17, "Jean-Baptiste Onofré"  wrote:


Hi all,

as I will be in vacation tonight for one week (with probably a

"limited"

Internet connection, and my wife will watch me ;)), I have anticipated

the

Karaf board report, to give you the maximum of time to review.

So, I created the board report for March, 2013 here:
https://cwiki.apache.org/**confluence/display/KARAF/**Board+Reports<

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


Please review it and update it if I forgot something.

I plan to submit the report on March, 9 (as soon as I'm back from
vacation).

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












smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Discuss] Apache Karaf 2.3.1 RC in two weeks time?

2013-02-13 Thread Christoph Gritschenberger


Aries JMX 1.1.1 release-vote is still pending.

kind regards,
christoph

On 2013-02-13 14:24, Claus Ibsen wrote:

Hi

Just wonder about whats up with Karaf 2.3.1 ?


On Tue, Jan 8, 2013 at 6:16 PM, Jamie G.  wrote:

Hi All,

First off, happy new year to the community, secondly, I'd like to
schedule Apache Karaf 2.3.1 RC for two weeks time from now.

We have a lot of resolved issues at the moment, and several issues in
progress. I think 2 weeks should be sufficient to close up these
in-flight issues, then prep for the RC build.

Are there any issues that anyone sees as a show stopper that would
require a longer development window?

Cheers,
Jamie









smime.p7s
Description: S/MIME Cryptographic Signature

Re: [DISCUSS] 3rd party Karaf commands compatibility between 2.x and 3.x

2013-01-30 Thread Christoph Gritschenberger


At least CXF karaf-commands work just fine in both karaf 2.x and trunk

kind regards,
christoph

On 2013-01-30 12:16, Jean-Baptiste Onofré wrote:

Hi Ioannis,

The "problem" is there, but I don't consider as a problem, just a change ;)

For instance, the annotations (like @Command) are no more provided by
gogo but directly by Karaf (like org.apache.karaf.shell.commands.Command).

But, if a 3rd party application uses gogo annotation, it should still
work in Karaf as Karaf still use gogo runtime (I have to check).

Let me take a look.

Regards
JB

On 01/30/2013 12:11 PM, Ioannis Canellos wrote:

I am not sure if this is still the case, so please forgive me if the
problem no longer applies, but it seems that all 3rd party projects that
provide Karaf commands, can't possibly have a bundle that will work both
2.x and 3.x.

This is mostly due to the fact that in 3.x we no longer provide or use
the
gogo annotations for commands, options and arguments. Unless we manage to
solve this one, all projects that provide integration with the karaf
shell
would need to rewrite their commands for 3.x, which is a bit annoying if
not frustrating.

So, I was wondering:

is it still an issue?
is there a workable work around this?
are there additional issues that will totally break compatibility and
thus
there is no reason to put any effort on this one?
should we rethink about dumping the gogo annotations?








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [DISCUSS] Switching to Git

2013-01-16 Thread Christoph Gritschenberger


How would this affect other projects in karaf-context (cellar, eik, ...)

Would each of them get their own git-repository or would they stay in 
svn for the moment?


kind regards,
christoph


On 2013-01-16 16:53, Jean-Baptiste Onofré wrote:

+1

I already use git-svn.
We just have to remember a couple of changes to do (scm URL mostly).

Regards
JB

On 01/16/2013 10:10 AM, Guillaume Nodet wrote:

What do you guys think about switching from svn to git ?
I think most of us already use git-svn so I think it would benefit us all
to use a native git repo instead.








smime.p7s
Description: S/MIME Cryptographic Signature

Re: Clean karaf.data/cache or karaf.data (KARAF-1563)

2013-01-04 Thread Christoph Gritschenberger

The option descriptions are the same for "clean", and "clean cache".
Aside from that, the patch works great.

kind regards,
christoph

On 02/01/13 10:28, Andreas Pieber wrote:
> Hey guys,
> 
> I've attached a patch to [1]. Basically what it enables you is to either
> delete your entire data folder on every reboot (or only the cache
> directory). In addition the same options had been added to the restart
> command. Finally the same option is also possible "one-time" by putting a
> clean_all or clean_cache file into your data folder. Does this make sense
> to you? Any further extensions wished for? Otherwise I'll apply to karaf
> 2.4 and 3.0
> 
> Kind regards,
> Andreas
> 
> [1] https://issues.apache.org/jira/browse/KARAF-1563
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: java 7 osgi core & compendium

2012-11-16 Thread Christoph Gritschenberger

Hi JB,

What's the status on the osgi-4.3.1-upgrade on trunk? Is there anything
missing or not working yet?

I'd be happy to help.

kind regards,
christoph

On 08/11/12 20:46, Jean-Baptiste Onofré wrote:
> Hi Christoph,
> 
> I already updated on Karaf 2.3.x (yesterday), and trunk is ready on my
> git local (I will commit tonight or tomorrow).
> 
> Regards
> JB
> 
> On 11/08/2012 03:03 PM, Christoph Gritschenberger wrote:
>> osgi core and compendium 4.3.1 are now available in central
>>
>> kind regards,
>> christoph
>>
>> On 02/11/12 09:48, Jean-Baptiste Onofré wrote:
>>> No problem for me as well.
>>>
>>> I'm just waiting for the artifact present on Central to commit what I
>>> did.
>>>
>>> Regards
>>> JB
>>>
>>> On 11/02/2012 09:44 AM, Christoph Gritschenberger wrote:
>>>> I compiled karaf with the 4.3.1-jars without a problem. Here is what I
>>>> did:
>>>>
>>>> * Download the jars from osgi.org [1] [2]
>>>> * install them to my local maven-repo
>>>>  mvn install:install-file -Dfile=osgi.core-4.3.1.jar
>>>> -DgroupId=org.osgi
>>>> -DartifactId=org.osgi.core -Dversion=4.3.1 -Dpackaging=jar
>>>>  mvn install:install-file -Dfile=osgi.cmpn-4.3.1.jar
>>>> -DgroupId=org.osgi
>>>> -DartifactId=org.osgi.compendium -Dversion=4.3.1 -Dpackaging=jar
>>>> * Replace all "org.apache.karaf.osgi" with "org.osgi"
>>>> * fix some hardcoded versions
>>>>
>>>> The I was able to compile without tests (-DskipTests)
>>>> The test-compile only fails for regression. As it's not the only place
>>>> where the generics are used, I think the jars are not at fault here.
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>> [1]
>>>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.core-4.3.1.jar
>>>>
>>>> [2]
>>>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.cmpn-4.3.1.jar
>>>>
>>>>
>>>> On 01/11/12 17:50, Andrei Pozolotin wrote:
>>>>> JB:
>>>>>
>>>>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>
>>>>> I tried to migrate karaf trunk to new osgi 4.3.1
>>>>> https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1
>>>>>
>>>>> so far compile fails. I hope JB has better luck.
>>>>>
>>>>>
>>>>>  Original Message 
>>>>> Subject: Re: java 7 osgi core & compendium
>>>>> From: Jean-Baptiste Onofré 
>>>>> To: d...@felix.apache.org
>>>>> Date: Tue 30 Oct 2012 05:26:53 AM CDT
>>>>>> Thanks David,
>>>>>>
>>>>>> I gonna make a try in Karaf.
>>>>>>
>>>>>> I keep you posted.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 10/30/2012 11:24 AM, David Bosschaert wrote:
>>>>>>> I've uploaded the 4.3.1 jars to the Maven Central staging area. It
>>>>>>> would be great if someone could check that they are indeed working
>>>>>>> fine and properly signed.
>>>>>>>
>>>>>>> See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 8 October 2012 20:45, Andrei Pozolotin
>>>>>>>  wrote:
>>>>>>>> David:
>>>>>>>>
>>>>>>>> great! thank you.
>>>>>>>>
>>>>>>>> I answered back on
>>>>>>>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>>>
>>>>>>>> Andrei.
>>>>>>>>
>>>>>>>>
>>>>>>>>  Original Message 
>>>>>>>> Subject: Re: java 7 osgi core & compendium
>>>>>>>> From: David Bosschaert 
>>>>>>>> To: d...@felix.apache.org
>>>>>>>> Date: Mon 08 Oct 2012 03:05:18 AM CDT
>>>>>>>>
>>>>>>>> Hi Andrei,
>>>>>>>>
>>>>>>>> I left a comment on that bug and reassigned it to me, as I have
>>>>>>>> been
>>>>>>>> the one who uploaded OSGi Artifacts to Maven in the recent past.
>>>>>>>> I would be happy to help getting OSGi 4.3 artifacts in maven that
>>>>>>>> work
>>>>>>>> with Java 7.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 5 October 2012 20:03, Andrei Pozolotin
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>*Felix and Jean-Baptiste*:
>>>>>>>>
>>>>>>>>since osgi alliance does not want to take responsibility for
>>>>>>>> this
>>>>>>>>https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>>>
>>>>>>>>1) do you think it would be appropriate for felix or
>>>>>>>> karaf to
>>>>>>>> step in,
>>>>>>>>and to produce and maintain shared java 7 osgi core &
>>>>>>>> compendium
>>>>>>>>jars for all of us?
>>>>>>>>
>>>>>>>>2) or else should everyone continue to bake their own?
>>>>>>>>
>>>>>>>>3) if shared, can you agree who should lead?
>>>>>>>>
>>>>>>>>Thank you,
>>>>>>>>
>>>>>>>>Andrei
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: java 7 osgi core & compendium

2012-11-09 Thread Christoph Gritschenberger

Hi,

The only change is full JDK-7 compatibility [1] of the jars. The code
has not changed at all.

kind regards,
christoph

[1] http://blog.osgi.org/2012/10/43-companion-code-for-java-7.html

On 09/11/12 11:27, Claus Ibsen wrote:
> Hi
> 
> On Thu, Nov 8, 2012 at 3:03 PM, Christoph Gritschenberger
>  wrote:
>> osgi core and compendium 4.3.1 are now available in central
>>
> 
> Are there any changes in 4.3.0 -> 4.3.1 that is good to know?
> And why would you want to upgrade?
> 
>> kind regards,
>> christoph
>>
>> On 02/11/12 09:48, Jean-Baptiste Onofré wrote:
>>> No problem for me as well.
>>>
>>> I'm just waiting for the artifact present on Central to commit what I did.
>>>
>>> Regards
>>> JB
>>>
>>> On 11/02/2012 09:44 AM, Christoph Gritschenberger wrote:
>>>> I compiled karaf with the 4.3.1-jars without a problem. Here is what I
>>>> did:
>>>>
>>>> * Download the jars from osgi.org [1] [2]
>>>> * install them to my local maven-repo
>>>> mvn install:install-file -Dfile=osgi.core-4.3.1.jar
>>>> -DgroupId=org.osgi
>>>> -DartifactId=org.osgi.core -Dversion=4.3.1 -Dpackaging=jar
>>>> mvn install:install-file -Dfile=osgi.cmpn-4.3.1.jar
>>>> -DgroupId=org.osgi
>>>> -DartifactId=org.osgi.compendium -Dversion=4.3.1 -Dpackaging=jar
>>>> * Replace all "org.apache.karaf.osgi" with "org.osgi"
>>>> * fix some hardcoded versions
>>>>
>>>> The I was able to compile without tests (-DskipTests)
>>>> The test-compile only fails for regression. As it's not the only place
>>>> where the generics are used, I think the jars are not at fault here.
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>> [1]
>>>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.core-4.3.1.jar
>>>> [2]
>>>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.cmpn-4.3.1.jar
>>>>
>>>> On 01/11/12 17:50, Andrei Pozolotin wrote:
>>>>> JB:
>>>>>
>>>>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>
>>>>> I tried to migrate karaf trunk to new osgi 4.3.1
>>>>> https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1
>>>>>
>>>>> so far compile fails. I hope JB has better luck.
>>>>>
>>>>>
>>>>>  Original Message 
>>>>> Subject: Re: java 7 osgi core & compendium
>>>>> From: Jean-Baptiste Onofré 
>>>>> To: d...@felix.apache.org
>>>>> Date: Tue 30 Oct 2012 05:26:53 AM CDT
>>>>>> Thanks David,
>>>>>>
>>>>>> I gonna make a try in Karaf.
>>>>>>
>>>>>> I keep you posted.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 10/30/2012 11:24 AM, David Bosschaert wrote:
>>>>>>> I've uploaded the 4.3.1 jars to the Maven Central staging area. It
>>>>>>> would be great if someone could check that they are indeed working
>>>>>>> fine and properly signed.
>>>>>>>
>>>>>>> See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 8 October 2012 20:45, Andrei Pozolotin
>>>>>>>  wrote:
>>>>>>>> David:
>>>>>>>>
>>>>>>>> great! thank you.
>>>>>>>>
>>>>>>>> I answered back on https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>>>
>>>>>>>> Andrei.
>>>>>>>>
>>>>>>>>
>>>>>>>>  Original Message 
>>>>>>>> Subject: Re: java 7 osgi core & compendium
>>>>>>>> From: David Bosschaert 
>>>>>>>> To: d...@felix.apache.org
>>>>>>>> Date: Mon 08 Oct 2012 03:05:18 AM CDT
>>>>>>>>
>>>>>>>> Hi Andrei,
>>>>>>>>
>>>>>>>> I left a comment on that bug and reassigned it to me, as I have been
>>>>>>>> the one who uploaded OSGi Artifacts to Maven in the recent past.
>>>>>>>> I would be happy to help getting OSGi 4.3 artifacts in maven that
>>>>>>>> work
>>>>>>>> with Java 7.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 5 October 2012 20:03, Andrei Pozolotin
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>   *Felix and Jean-Baptiste*:
>>>>>>>>
>>>>>>>>   since osgi alliance does not want to take responsibility for
>>>>>>>> this
>>>>>>>>   https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>>>
>>>>>>>>   1) do you think it would be appropriate for felix or karaf to
>>>>>>>> step in,
>>>>>>>>   and to produce and maintain shared java 7 osgi core &
>>>>>>>> compendium
>>>>>>>>   jars for all of us?
>>>>>>>>
>>>>>>>>   2) or else should everyone continue to bake their own?
>>>>>>>>
>>>>>>>>   3) if shared, can you agree who should lead?
>>>>>>>>
>>>>>>>>   Thank you,
>>>>>>>>
>>>>>>>>   Andrei
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
> 
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: java 7 osgi core & compendium

2012-11-09 Thread Christoph Gritschenberger

Hi JB,

Thanks for the update.

kind regards,
christoph

On 08/11/12 20:46, Jean-Baptiste Onofré wrote:
> Hi Christoph,
> 
> I already updated on Karaf 2.3.x (yesterday), and trunk is ready on my
> git local (I will commit tonight or tomorrow).
> 
> Regards
> JB
> 
> On 11/08/2012 03:03 PM, Christoph Gritschenberger wrote:
>> osgi core and compendium 4.3.1 are now available in central
>>
>> kind regards,
>> christoph
>>
>> On 02/11/12 09:48, Jean-Baptiste Onofré wrote:
>>> No problem for me as well.
>>>
>>> I'm just waiting for the artifact present on Central to commit what I
>>> did.
>>>
>>> Regards
>>> JB
>>>
>>> On 11/02/2012 09:44 AM, Christoph Gritschenberger wrote:
>>>> I compiled karaf with the 4.3.1-jars without a problem. Here is what I
>>>> did:
>>>>
>>>> * Download the jars from osgi.org [1] [2]
>>>> * install them to my local maven-repo
>>>>  mvn install:install-file -Dfile=osgi.core-4.3.1.jar
>>>> -DgroupId=org.osgi
>>>> -DartifactId=org.osgi.core -Dversion=4.3.1 -Dpackaging=jar
>>>>  mvn install:install-file -Dfile=osgi.cmpn-4.3.1.jar
>>>> -DgroupId=org.osgi
>>>> -DartifactId=org.osgi.compendium -Dversion=4.3.1 -Dpackaging=jar
>>>> * Replace all "org.apache.karaf.osgi" with "org.osgi"
>>>> * fix some hardcoded versions
>>>>
>>>> The I was able to compile without tests (-DskipTests)
>>>> The test-compile only fails for regression. As it's not the only place
>>>> where the generics are used, I think the jars are not at fault here.
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>> [1]
>>>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.core-4.3.1.jar
>>>>
>>>> [2]
>>>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.cmpn-4.3.1.jar
>>>>
>>>>
>>>> On 01/11/12 17:50, Andrei Pozolotin wrote:
>>>>> JB:
>>>>>
>>>>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>
>>>>> I tried to migrate karaf trunk to new osgi 4.3.1
>>>>> https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1
>>>>>
>>>>> so far compile fails. I hope JB has better luck.
>>>>>
>>>>>
>>>>>  Original Message 
>>>>> Subject: Re: java 7 osgi core & compendium
>>>>> From: Jean-Baptiste Onofré 
>>>>> To: d...@felix.apache.org
>>>>> Date: Tue 30 Oct 2012 05:26:53 AM CDT
>>>>>> Thanks David,
>>>>>>
>>>>>> I gonna make a try in Karaf.
>>>>>>
>>>>>> I keep you posted.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>> On 10/30/2012 11:24 AM, David Bosschaert wrote:
>>>>>>> I've uploaded the 4.3.1 jars to the Maven Central staging area. It
>>>>>>> would be great if someone could check that they are indeed working
>>>>>>> fine and properly signed.
>>>>>>>
>>>>>>> See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 8 October 2012 20:45, Andrei Pozolotin
>>>>>>>  wrote:
>>>>>>>> David:
>>>>>>>>
>>>>>>>> great! thank you.
>>>>>>>>
>>>>>>>> I answered back on
>>>>>>>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>>>
>>>>>>>> Andrei.
>>>>>>>>
>>>>>>>>
>>>>>>>>  Original Message 
>>>>>>>> Subject: Re: java 7 osgi core & compendium
>>>>>>>> From: David Bosschaert 
>>>>>>>> To: d...@felix.apache.org
>>>>>>>> Date: Mon 08 Oct 2012 03:05:18 AM CDT
>>>>>>>>
>>>>>>>> Hi Andrei,
>>>>>>>>
>>>>>>>> I left a comment on that bug and reassigned it to me, as I have
>>>>>>>> been
>>>>>>>> the one who uploaded OSGi Artifacts to Maven in the recent past.
>>>>>>>> I would be happy to help getting OSGi 4.3 artifacts in maven that
>>>>>>>> work
>>>>>>>> with Java 7.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 5 October 2012 20:03, Andrei Pozolotin
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>*Felix and Jean-Baptiste*:
>>>>>>>>
>>>>>>>>since osgi alliance does not want to take responsibility for
>>>>>>>> this
>>>>>>>>https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>>>
>>>>>>>>1) do you think it would be appropriate for felix or
>>>>>>>> karaf to
>>>>>>>> step in,
>>>>>>>>and to produce and maintain shared java 7 osgi core &
>>>>>>>> compendium
>>>>>>>>jars for all of us?
>>>>>>>>
>>>>>>>>2) or else should everyone continue to bake their own?
>>>>>>>>
>>>>>>>>3) if shared, can you agree who should lead?
>>>>>>>>
>>>>>>>>Thank you,
>>>>>>>>
>>>>>>>>Andrei
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: java 7 osgi core & compendium

2012-11-08 Thread Christoph Gritschenberger

osgi core and compendium 4.3.1 are now available in central

kind regards,
christoph

On 02/11/12 09:48, Jean-Baptiste Onofré wrote:
> No problem for me as well.
> 
> I'm just waiting for the artifact present on Central to commit what I did.
> 
> Regards
> JB
> 
> On 11/02/2012 09:44 AM, Christoph Gritschenberger wrote:
>> I compiled karaf with the 4.3.1-jars without a problem. Here is what I
>> did:
>>
>> * Download the jars from osgi.org [1] [2]
>> * install them to my local maven-repo
>> mvn install:install-file -Dfile=osgi.core-4.3.1.jar
>> -DgroupId=org.osgi
>> -DartifactId=org.osgi.core -Dversion=4.3.1 -Dpackaging=jar
>> mvn install:install-file -Dfile=osgi.cmpn-4.3.1.jar
>> -DgroupId=org.osgi
>> -DartifactId=org.osgi.compendium -Dversion=4.3.1 -Dpackaging=jar
>> * Replace all "org.apache.karaf.osgi" with "org.osgi"
>> * fix some hardcoded versions
>>
>> The I was able to compile without tests (-DskipTests)
>> The test-compile only fails for regression. As it's not the only place
>> where the generics are used, I think the jars are not at fault here.
>>
>> kind regards,
>> christoph
>>
>> [1]
>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.core-4.3.1.jar
>> [2]
>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.cmpn-4.3.1.jar
>>
>> On 01/11/12 17:50, Andrei Pozolotin wrote:
>>> JB:
>>>
>>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>
>>> I tried to migrate karaf trunk to new osgi 4.3.1
>>> https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1
>>>
>>> so far compile fails. I hope JB has better luck.
>>>
>>>
>>>  Original Message 
>>> Subject: Re: java 7 osgi core & compendium
>>> From: Jean-Baptiste Onofré 
>>> To: d...@felix.apache.org
>>> Date: Tue 30 Oct 2012 05:26:53 AM CDT
>>>> Thanks David,
>>>>
>>>> I gonna make a try in Karaf.
>>>>
>>>> I keep you posted.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 10/30/2012 11:24 AM, David Bosschaert wrote:
>>>>> I've uploaded the 4.3.1 jars to the Maven Central staging area. It
>>>>> would be great if someone could check that they are indeed working
>>>>> fine and properly signed.
>>>>>
>>>>> See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13
>>>>>
>>>>> Thanks,
>>>>>
>>>>> David
>>>>>
>>>>> On 8 October 2012 20:45, Andrei Pozolotin
>>>>>  wrote:
>>>>>> David:
>>>>>>
>>>>>> great! thank you.
>>>>>>
>>>>>> I answered back on https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>
>>>>>> Andrei.
>>>>>>
>>>>>>
>>>>>>  Original Message 
>>>>>> Subject: Re: java 7 osgi core & compendium
>>>>>> From: David Bosschaert 
>>>>>> To: d...@felix.apache.org
>>>>>> Date: Mon 08 Oct 2012 03:05:18 AM CDT
>>>>>>
>>>>>> Hi Andrei,
>>>>>>
>>>>>> I left a comment on that bug and reassigned it to me, as I have been
>>>>>> the one who uploaded OSGi Artifacts to Maven in the recent past.
>>>>>> I would be happy to help getting OSGi 4.3 artifacts in maven that
>>>>>> work
>>>>>> with Java 7.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 5 October 2012 20:03, Andrei Pozolotin
>>>>>> 
>>>>>> wrote:
>>>>>>
>>>>>>   *Felix and Jean-Baptiste*:
>>>>>>
>>>>>>   since osgi alliance does not want to take responsibility for
>>>>>> this
>>>>>>   https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>
>>>>>>   1) do you think it would be appropriate for felix or karaf to
>>>>>> step in,
>>>>>>   and to produce and maintain shared java 7 osgi core &
>>>>>> compendium
>>>>>>   jars for all of us?
>>>>>>
>>>>>>   2) or else should everyone continue to bake their own?
>>>>>>
>>>>>>   3) if shared, can you agree who should lead?
>>>>>>
>>>>>>   Thank you,
>>>>>>
>>>>>>   Andrei
>>>>>>
>>>>>>
>>>>
>>>
>>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: java 7 osgi core & compendium

2012-11-02 Thread Christoph Gritschenberger

It seems David Bosschaert is still waiting for some validation of the
jars [1].

kind regards,
christoph

[1] https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13

On 02/11/12 09:48, Jean-Baptiste Onofré wrote:
> No problem for me as well.
> 
> I'm just waiting for the artifact present on Central to commit what I did.
> 
> Regards
> JB
> 
> On 11/02/2012 09:44 AM, Christoph Gritschenberger wrote:
>> I compiled karaf with the 4.3.1-jars without a problem. Here is what I
>> did:
>>
>> * Download the jars from osgi.org [1] [2]
>> * install them to my local maven-repo
>> mvn install:install-file -Dfile=osgi.core-4.3.1.jar
>> -DgroupId=org.osgi
>> -DartifactId=org.osgi.core -Dversion=4.3.1 -Dpackaging=jar
>> mvn install:install-file -Dfile=osgi.cmpn-4.3.1.jar
>> -DgroupId=org.osgi
>> -DartifactId=org.osgi.compendium -Dversion=4.3.1 -Dpackaging=jar
>> * Replace all "org.apache.karaf.osgi" with "org.osgi"
>> * fix some hardcoded versions
>>
>> The I was able to compile without tests (-DskipTests)
>> The test-compile only fails for regression. As it's not the only place
>> where the generics are used, I think the jars are not at fault here.
>>
>> kind regards,
>> christoph
>>
>> [1]
>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.core-4.3.1.jar
>> [2]
>> http://www.osgi.org/Download/File?url=/download/r4v43/osgi.cmpn-4.3.1.jar
>>
>> On 01/11/12 17:50, Andrei Pozolotin wrote:
>>> JB:
>>>
>>> https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>
>>> I tried to migrate karaf trunk to new osgi 4.3.1
>>> https://github.com/carrot-garden/carrot-apache-karaf/tree/osgi-4.3.1
>>>
>>> so far compile fails. I hope JB has better luck.
>>>
>>>
>>>  Original Message 
>>> Subject: Re: java 7 osgi core & compendium
>>> From: Jean-Baptiste Onofré 
>>> To: d...@felix.apache.org
>>> Date: Tue 30 Oct 2012 05:26:53 AM CDT
>>>> Thanks David,
>>>>
>>>> I gonna make a try in Karaf.
>>>>
>>>> I keep you posted.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 10/30/2012 11:24 AM, David Bosschaert wrote:
>>>>> I've uploaded the 4.3.1 jars to the Maven Central staging area. It
>>>>> would be great if someone could check that they are indeed working
>>>>> fine and properly signed.
>>>>>
>>>>> See: https://www.osgi.org/bugzilla/show_bug.cgi?id=153#c13
>>>>>
>>>>> Thanks,
>>>>>
>>>>> David
>>>>>
>>>>> On 8 October 2012 20:45, Andrei Pozolotin
>>>>>  wrote:
>>>>>> David:
>>>>>>
>>>>>> great! thank you.
>>>>>>
>>>>>> I answered back on https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>
>>>>>> Andrei.
>>>>>>
>>>>>>
>>>>>>  Original Message 
>>>>>> Subject: Re: java 7 osgi core & compendium
>>>>>> From: David Bosschaert 
>>>>>> To: d...@felix.apache.org
>>>>>> Date: Mon 08 Oct 2012 03:05:18 AM CDT
>>>>>>
>>>>>> Hi Andrei,
>>>>>>
>>>>>> I left a comment on that bug and reassigned it to me, as I have been
>>>>>> the one who uploaded OSGi Artifacts to Maven in the recent past.
>>>>>> I would be happy to help getting OSGi 4.3 artifacts in maven that
>>>>>> work
>>>>>> with Java 7.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 5 October 2012 20:03, Andrei Pozolotin
>>>>>> 
>>>>>> wrote:
>>>>>>
>>>>>>   *Felix and Jean-Baptiste*:
>>>>>>
>>>>>>   since osgi alliance does not want to take responsibility for
>>>>>> this
>>>>>>   https://www.osgi.org/bugzilla/show_bug.cgi?id=153
>>>>>>
>>>>>>   1) do you think it would be appropriate for felix or karaf to
>>>>>> step in,
>>>>>>   and to produce and maintain shared java 7 osgi core &
>>>>>> compendium
>>>>>>   jars for all of us?
>>>>>>
>>>>>>   2) or else should everyone continue to bake their own?
>>>>>>
>>>>>>   3) if shared, can you agree who should lead?
>>>>>>
>>>>>>   Thank you,
>>>>>>
>>>>>>   Andrei
>>>>>>
>>>>>>
>>>>
>>>
>>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PROPOSAL] Create "Karaf Features" sub-project

2012-10-18 Thread Christoph Gritschenberger

Sounds like a good idea.

Wouldn't it also make sense to include the recompiled osgi-4.3-specs
there? JB once said on IRC that the plan was to include them in felix,
but until that happens maybe that's a place to put them.

kind regards,
christoph

On 18/10/12 09:09, Charles Moulliard wrote:
> I completely agree with this idea. That could also help us to provide a
> kind of "web" repo of the different features available and include more
> like Pax Web, KarafEE, Camel, CXf, ActiveMQ, JClouds, 
> 
> On Thu, Oct 18, 2012 at 9:04 AM, Jean-Baptiste Onofré 
> wrote:
> 
>> Hi all,
>>
>> Currently, Karaf provides features that it doesn't use directly and
>> internally.
>>
>> For instance, it's the case for:
>> - enterprise features (leveraging Aries),
>> - spring features
>>
>> As those features are provided by Karaf, the features version is coupled
>> to the Karaf version.
>> For instance, Karaf 2.3.0 provides Spring 3.0.x features, and providing
>> Spring 3.1 features or just upgrading to a new Spring 3.0.x features
>> requires a new Karaf release.
>> It's not very flexible, and it doesn't give to the users the liberty of
>> picking up the version that he wants.
>>
>> My proposal is to create a Karaf Features sub-project where we can host
>> this kind of features. Each feature has its own release cycle, allowing to
>> completely decoupled from the Karaf release.
>>
>> From an user perspective, it's just mean to addurl of the corresponding
>> features descriptor that I want (or use the new chooseurl command).
>>
>> More over, some projects may provide bundles but not the corresponding
>> Karaf features. So waiting for our contribution to those projects, we can
>> provide features descriptor.
>>
>> If you are OK, I would like to begin by creating a sub-project looking
>> like:
>>
>> https://svn.apache.org/repos/**asf/karaf
>> -> features
>> --> enterprise
>> --> spring
>> Each features should be atomic and independent from another.
>>
>> NB: we discussed some months ago about providing Karaf Features Repository
>> in Cave. This step could a "transition" step to that.
>>
>> WDYT ?
>>
>> Regards
>> JB
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
> 
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: can not compile trunk

2012-10-03 Thread Christoph Gritschenberger

Ich think the only solution to make the generics work is to recompile
the compendium just like it is done for the OSGi-core right now.
This would also make the whole thing more consistent imho. e.g. now you
can use generics with a ServiceReference, but not a ServiceTracker.

kind regards,
christoph

On 04/10/12 00:00, Christian Schneider wrote:
> +1
> 
> and for the generics. As there seems to be no working solution I will
> remove them.
> 
> Christian
> 
> Am 03.10.2012 23:51, schrieb Andrei Pozolotin:
>> @JB: I think it would make sense to have 2 jenkins build projects: with
>> both java 6 and java 7
>>
>>  Original Message 
>> Subject: Re: can not compile trunk
>> From: Jean-Baptiste Onofré 
>> To: dev@karaf.apache.org
>> Date: Wed 03 Oct 2012 02:12:42 PM CDT
>>> It works with Java6 (1.6.0_26 on my machine), but not with Java7
>>> (1.7.0 on my machine).
>>>
>>> I gonna update Jenkins to use Java7.
>>>
>>> @Christian, keep in mind that Karaf 3.0.0 should compile and run with
>>> both Java6 AND Java7. When I commit something on trunk I always
>>> compile and run with both JDK, maybe you could do the same.
>>>
>>> Regards
>>> JB
>>>
>>> On 10/03/2012 07:57 PM, Christian Schneider wrote:
 Hi Andrei,

 this was changed by me. What is your build environment?
 On my system and on jenkins it seems to build.

 Christian


 Am 03.10.2012 19:54, schrieb Jean-Baptiste Onofré:
> Thanks Andrei,
>
> I gonna make a try on my local working copy.
>
> Regards
> JB
>
> On 10/03/2012 07:07 PM, Andrei Pozolotin wrote:
>>   *JB:*
>>
>>   my guess is someone is trying to play with compendium 4.3.0
>>
>>   FYI:
>>
>>   cd /tmp
>>   mkdir apache
>>   cd apache
>>   git clone git://github.com/apache/karaf.git
>>   cd karaf
>>   mvn clean install --define skipTests
>>
>>   result:
>>
>>   [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
>>   (default-compile) on project org.apache.karaf.features.core:
>>   Compilation failure: Compilation failure:
>>   [ERROR]
>> /tmp/apache/karaf/features/core/src/main/java/org/apache/karaf/features/internal/EventAdminListener.java:[36,32]
>>
>>
>>
>>   error: type ServiceTracker does not take parameters
>>   [ERROR]
>> /tmp/apache/karaf/features/core/src/main/java/org/apache/karaf/features/internal/BundleManager.java:[184,26]
>>
>>
>>
>>   error: type ServiceTracker does not take parameters
>>   [ERROR]
>> /tmp/apache/karaf/features/core/src/main/java/org/apache/karaf/features/internal/BundleManager.java:[184,115]
>>
>>
>>
>>   error: type ServiceTracker does not take parameters
>>   [ERROR]
>> /tmp/apache/karaf/features/core/src/main/java/org/apache/karaf/features/internal/FeaturesServiceImpl.java:[565,22]
>>
>>
>>
>>   error: type ServiceTracker does not take parameters
>>   [ERROR]
>> /tmp/apache/karaf/features/core/src/main/java/org/apache/karaf/features/internal/EventAdminListener.java:[39,36]
>>
>>
>>
>>   error: type ServiceTracker does not take parameters
>>   [ERROR] -> [Help 1]
>>
>>   Thank you,
>>
>>   Andrei
>>
>>
>>   [INFO]
>> 
>>
>>
>>   [INFO] Reactor Summary:
>>   [INFO]
>>   [INFO] Apache Karaf ..
>> SUCCESS
>>   [1.288s]
>>   [INFO] OSGi core spec compiled for Java 7 
>> SUCCESS
>>   [3.307s]
>>   [INFO] Apache Karaf :: Util ..
>> SUCCESS
>>   [0.392s]
>>   [INFO] Apache Karaf :: Main ..
>> SUCCESS
>>   [1.382s]
>>   [INFO] Apache Karaf :: Region 
>> SUCCESS
>>   [0.025s]
>>   [INFO] Apache Karaf :: Region :: Core 
>> SUCCESS
>>   [0.472s]
>>   [INFO] Apache Karaf :: Features ..
>> SUCCESS
>>   [0.028s]
>>   [INFO] Apache Karaf :: Features :: Core ..
>> FAILURE
>>   [0.392s]
>>   [INFO] Apache Karaf :: Shell .
>> SKIPPED
>>   [INFO] Apache Karaf :: Shell :: Table 
>> SKIPPED
>>   [INFO] Apache Karaf :: JAAS ..
>> SKIPPED
>>   [INFO] Apache Karaf :: JAAS :: Boot ..
>> SKIPPED
>>   [INFO] Apache Karaf :: JAAS :: Config 
>> SKIPPED
>>   [INFO] Apache Karaf :: JAAS :: Modules ...

Re: framework kar is not deployed sometimes

2012-10-02 Thread Christoph Gritschenberger

Hi,

Any news on this? It's still happening.

kind regards
christoph

On 05/09/12 10:36, Christoph Gritschenberger wrote:
> Hi,
> 
> I took a look at the build-log. The first deploy during the build seems
> to work correctly. Then after successful build the Maven
> RedeployPublisher deploys it again. There a new pom is uploaded (with a
> new version) and the other artifacts are reuploaded with the old version
> number:
> 
> framework-3.0.0-20120905.003625-517.pom
> framework-3.0.0-20120905.001606-516-features.xml
> framework-3.0.0-20120905.001606-516.kar
> 
> So the redeploy causes the repo to be somehow corrupt.
> I extracted the relevant log-sections from jenkins:
> 
> 
> kind regards,
> christoph
> 
> On 04/09/12 08:16, Christoph Gritschenberger wrote:
>> I just did some tests deploying karaf-trunk-snapshots to my own
>> artifactory-instance. It worked without problems. Looking at the
>> timestamps of the poms, there could be something wrong with a
>> build-server setup.
>>
>> It appears a pom is uploaded at some time. About 20-30 min later the kar
>> and the features.xml are attached to that old pom and a new pom is
>> uploaded (without the artifacts).
>>
>> kind regards,
>> christoph
>>
>>
>> On 31/08/12 17:57, Jean-Baptiste Onofré wrote:
>>> Hi Christoph,
>>>
>>> locally it's OK, so I think it's just a maven deploy issue (maybe about
>>> the type), I gonna take a look.
>>>
>>> Regards
>>> JB
>>>
>>> On 08/29/2012 04:06 PM, Christoph Gritschenberger wrote:
>>>> Hi,
>>>>
>>>> Sometimes when compiling our karaf-based (3.0.0-SNAPSHOT) project I get
>>>> the following Exception:
>>>>
>>>>
>>>> The following artifacts could not be resolved:
>>>> org.apache.karaf.features:framework:kar:3.0.0-SNAPSHOT,
>>>> org.apache.karaf.features:standard:xml:features:3.0.0-SNAPSHOT,
>>>> org.apache.karaf.features:spring:xml:features:3.0.0-SNAPSHOT,
>>>> org.apache.karaf.features:enterprise:xml:features:3.0.0-SNAPSHOT: Could
>>>> not find artifact
>>>> org.apache.karaf.features:framework:kar:3.0.0-20120829.013834-494 in
>>>> apache.snapshots
>>>> (https://repository.apache.org/content/repositories/snapshots/) ->
>>>> [Help 1]
>>>>
>>>>
>>>> I then checked the repository and discovered that indeed the file is not
>>>> there. It seems only every other build actually deploys the .kar.
>>>> This is the current content of the repo.
>>>>
>>>> framework-3.0.0-20120828.003502-491-features.xml
>>>> framework-3.0.0-20120828.003502-491.kar
>>>> framework-3.0.0-20120828.003502-491.pom
>>>> framework-3.0.0-20120828.005642-492.pom
>>>> framework-3.0.0-20120829.010155-493-features.xml
>>>> framework-3.0.0-20120829.010155-493.kar
>>>> framework-3.0.0-20120829.010155-493.pom
>>>> framework-3.0.0-20120829.013834-494.pom
>>>> framework-3.0.0-20120829.110601-495-features.xml
>>>> framework-3.0.0-20120829.110601-495.kar
>>>> framework-3.0.0-20120829.110601-495.pom
>>>> framework-3.0.0-20120829.112704-496.pom
>>>> framework-3.0.0-20120829.132521-497-features.xml
>>>> framework-3.0.0-20120829.132521-497.kar
>>>> framework-3.0.0-20120829.132521-497.pom
>>>> framework-3.0.0-20120829.134656-498.pom
>>>>
>>>> The current deployed version of the pom comes without .kar and
>>>> features.xml.
>>>>
>>>> Any idea why?
>>>>
>>>> kind regards,
>>>> christoph
>>>>
>>>>
>>>
>>
>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: framework kar is not deployed sometimes

2012-09-05 Thread Christoph Gritschenberger

Hi,

I took a look at the build-log. The first deploy during the build seems
to work correctly. Then after successful build the Maven
RedeployPublisher deploys it again. There a new pom is uploaded (with a
new version) and the other artifacts are reuploaded with the old version
number:

framework-3.0.0-20120905.003625-517.pom
framework-3.0.0-20120905.001606-516-features.xml
framework-3.0.0-20120905.001606-516.kar

So the redeploy causes the repo to be somehow corrupt.
I extracted the relevant log-sections from jenkins:


kind regards,
christoph

On 04/09/12 08:16, Christoph Gritschenberger wrote:
> I just did some tests deploying karaf-trunk-snapshots to my own
> artifactory-instance. It worked without problems. Looking at the
> timestamps of the poms, there could be something wrong with a
> build-server setup.
> 
> It appears a pom is uploaded at some time. About 20-30 min later the kar
> and the features.xml are attached to that old pom and a new pom is
> uploaded (without the artifacts).
> 
> kind regards,
> christoph
> 
> 
> On 31/08/12 17:57, Jean-Baptiste Onofré wrote:
>> Hi Christoph,
>>
>> locally it's OK, so I think it's just a maven deploy issue (maybe about
>> the type), I gonna take a look.
>>
>> Regards
>> JB
>>
>> On 08/29/2012 04:06 PM, Christoph Gritschenberger wrote:
>>> Hi,
>>>
>>> Sometimes when compiling our karaf-based (3.0.0-SNAPSHOT) project I get
>>> the following Exception:
>>>
>>>
>>> The following artifacts could not be resolved:
>>> org.apache.karaf.features:framework:kar:3.0.0-SNAPSHOT,
>>> org.apache.karaf.features:standard:xml:features:3.0.0-SNAPSHOT,
>>> org.apache.karaf.features:spring:xml:features:3.0.0-SNAPSHOT,
>>> org.apache.karaf.features:enterprise:xml:features:3.0.0-SNAPSHOT: Could
>>> not find artifact
>>> org.apache.karaf.features:framework:kar:3.0.0-20120829.013834-494 in
>>> apache.snapshots
>>> (https://repository.apache.org/content/repositories/snapshots/) ->
>>> [Help 1]
>>>
>>>
>>> I then checked the repository and discovered that indeed the file is not
>>> there. It seems only every other build actually deploys the .kar.
>>> This is the current content of the repo.
>>>
>>> framework-3.0.0-20120828.003502-491-features.xml
>>> framework-3.0.0-20120828.003502-491.kar
>>> framework-3.0.0-20120828.003502-491.pom
>>> framework-3.0.0-20120828.005642-492.pom
>>> framework-3.0.0-20120829.010155-493-features.xml
>>> framework-3.0.0-20120829.010155-493.kar
>>> framework-3.0.0-20120829.010155-493.pom
>>> framework-3.0.0-20120829.013834-494.pom
>>> framework-3.0.0-20120829.110601-495-features.xml
>>> framework-3.0.0-20120829.110601-495.kar
>>> framework-3.0.0-20120829.110601-495.pom
>>> framework-3.0.0-20120829.112704-496.pom
>>> framework-3.0.0-20120829.132521-497-features.xml
>>> framework-3.0.0-20120829.132521-497.kar
>>> framework-3.0.0-20120829.132521-497.pom
>>> framework-3.0.0-20120829.134656-498.pom
>>>
>>> The current deployed version of the pom comes without .kar and
>>> features.xml.
>>>
>>> Any idea why?
>>>
>>> kind regards,
>>> christoph
>>>
>>>
>>
> 
> 


[...]
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ framework ---
Downloaded: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/3.0.0-SNAPSHOT/maven-metadata.xml (1007 B at 2.7 KB/sec)
Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/3.0.0-SNAPSHOT/framework-3.0.0-20120905.001606-516.pom
Uploaded: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/3.0.0-SNAPSHOT/framework-3.0.0-20120905.001606-516.pom (18 KB at 49.1 KB/sec)
Downloading: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/maven-metadata.xml
Downloaded: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/maven-metadata.xml (294 B at 1.3 KB/sec)
Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/3.0.0-SNAPSHOT/maven-metadata.xml
Uploaded: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/3.0.0-SNAPSHOT/maven-metadata.xml (1007 B at 3.0 KB/sec)
Uploading: https://repository.apache.org/content/repositories/snapshots/org/apache/karaf/features/framework/maven-metadata.xml
Uploaded

Re: framework kar is not deployed sometimes

2012-09-03 Thread Christoph Gritschenberger

I just did some tests deploying karaf-trunk-snapshots to my own
artifactory-instance. It worked without problems. Looking at the
timestamps of the poms, there could be something wrong with a
build-server setup.

It appears a pom is uploaded at some time. About 20-30 min later the kar
and the features.xml are attached to that old pom and a new pom is
uploaded (without the artifacts).

kind regards,
christoph


On 31/08/12 17:57, Jean-Baptiste Onofré wrote:
> Hi Christoph,
> 
> locally it's OK, so I think it's just a maven deploy issue (maybe about
> the type), I gonna take a look.
> 
> Regards
> JB
> 
> On 08/29/2012 04:06 PM, Christoph Gritschenberger wrote:
>> Hi,
>>
>> Sometimes when compiling our karaf-based (3.0.0-SNAPSHOT) project I get
>> the following Exception:
>>
>>
>> The following artifacts could not be resolved:
>> org.apache.karaf.features:framework:kar:3.0.0-SNAPSHOT,
>> org.apache.karaf.features:standard:xml:features:3.0.0-SNAPSHOT,
>> org.apache.karaf.features:spring:xml:features:3.0.0-SNAPSHOT,
>> org.apache.karaf.features:enterprise:xml:features:3.0.0-SNAPSHOT: Could
>> not find artifact
>> org.apache.karaf.features:framework:kar:3.0.0-20120829.013834-494 in
>> apache.snapshots
>> (https://repository.apache.org/content/repositories/snapshots/) ->
>> [Help 1]
>>
>>
>> I then checked the repository and discovered that indeed the file is not
>> there. It seems only every other build actually deploys the .kar.
>> This is the current content of the repo.
>>
>> framework-3.0.0-20120828.003502-491-features.xml
>> framework-3.0.0-20120828.003502-491.kar
>> framework-3.0.0-20120828.003502-491.pom
>> framework-3.0.0-20120828.005642-492.pom
>> framework-3.0.0-20120829.010155-493-features.xml
>> framework-3.0.0-20120829.010155-493.kar
>> framework-3.0.0-20120829.010155-493.pom
>> framework-3.0.0-20120829.013834-494.pom
>> framework-3.0.0-20120829.110601-495-features.xml
>> framework-3.0.0-20120829.110601-495.kar
>> framework-3.0.0-20120829.110601-495.pom
>> framework-3.0.0-20120829.112704-496.pom
>> framework-3.0.0-20120829.132521-497-features.xml
>> framework-3.0.0-20120829.132521-497.kar
>> framework-3.0.0-20120829.132521-497.pom
>> framework-3.0.0-20120829.134656-498.pom
>>
>> The current deployed version of the pom comes without .kar and
>> features.xml.
>>
>> Any idea why?
>>
>> kind regards,
>> christoph
>>
>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

framework kar is not deployed sometimes

2012-08-29 Thread Christoph Gritschenberger

Hi,

Sometimes when compiling our karaf-based (3.0.0-SNAPSHOT) project I get
the following Exception:


The following artifacts could not be resolved:
org.apache.karaf.features:framework:kar:3.0.0-SNAPSHOT,
org.apache.karaf.features:standard:xml:features:3.0.0-SNAPSHOT,
org.apache.karaf.features:spring:xml:features:3.0.0-SNAPSHOT,
org.apache.karaf.features:enterprise:xml:features:3.0.0-SNAPSHOT: Could
not find artifact
org.apache.karaf.features:framework:kar:3.0.0-20120829.013834-494 in
apache.snapshots
(https://repository.apache.org/content/repositories/snapshots/) -> [Help 1]


I then checked the repository and discovered that indeed the file is not
there. It seems only every other build actually deploys the .kar.
This is the current content of the repo.

framework-3.0.0-20120828.003502-491-features.xml
framework-3.0.0-20120828.003502-491.kar
framework-3.0.0-20120828.003502-491.pom
framework-3.0.0-20120828.005642-492.pom
framework-3.0.0-20120829.010155-493-features.xml
framework-3.0.0-20120829.010155-493.kar
framework-3.0.0-20120829.010155-493.pom
framework-3.0.0-20120829.013834-494.pom
framework-3.0.0-20120829.110601-495-features.xml
framework-3.0.0-20120829.110601-495.kar
framework-3.0.0-20120829.110601-495.pom
framework-3.0.0-20120829.112704-496.pom
framework-3.0.0-20120829.132521-497-features.xml
framework-3.0.0-20120829.132521-497.kar
framework-3.0.0-20120829.132521-497.pom
framework-3.0.0-20120829.134656-498.pom

The current deployed version of the pom comes without .kar and features.xml.

Any idea why?

kind regards,
christoph





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Latest karaf-2.3.x Hangs on Shutdown

2012-08-22 Thread Christoph Gritschenberger

Hi Scott,

I observed the same behaviour. I built it with jdk-6 (ignoring tests
because some itest was failing) and started the apache-karaf assembly.
When I enter the command "shutdown -f", the console remains active.
Karaf does not terminate and the thread dump looks similar to yours.

However I didn't notice the problem at first because I usually terminate
karaf with Ctrl+D. That way it actually does.

kind regards,
christoph


On 22/08/12 06:39, Scott England-Sullivan wrote:
> Hi All,
> 
> I built a fresh 2.3.0-SNAPSHOT from git svn karaf-2.3.x to port the SCR
> components.  With just the defaults installed, when I try to issue a
> shutdown or shutdown -f it just hangs and never completes.  I have to kill
> -9 the instance.
> 
> Pulling a thread dump, the FelixStartLevel thread is blocked:
> 
> "FelixStartLevel" daemon prio=5 tid=7feb5387f800 nid=0x10ab0b000 waiting
> for monitor entry [10ab0a000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.destroy(BlueprintContainerImpl.java:826)
> - waiting to lock <7d41963d0> (a java.util.concurrent.atomic.AtomicBoolean)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.destroyContext(BlueprintExtender.java:246)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:238)
> at
> org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:434)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:198)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:128)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:468)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:161)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:117)
> at
> org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)
> at
> org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2351)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1214)
> at
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
> at java.lang.Thread.run(Thread.java:680)
> 
> The full thread dump is attached.
> 
> Is anyone else seeing this?
> 
> TIA,
> 
> Scott ES
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Tentative Release Dates for 2.2.9 and.or 2.3.0?

2012-08-14 Thread Christoph Gritschenberger

We also got our integration-tests working by upgrading karaf to
2.2.9-SNAPSHOT. Proxy-issues are gone.

kind regards,
christoph

On 14/08/12 19:57, Jean-Baptiste Onofré wrote:
> Quick question: did you make some tests using the latest JDK 1.6 update
> (33) or JDK 1.7 ?
> 
> I fixed a couple of issues around Aries Proxy with these JDK updates,
> and I want to be sure that all use cases are covered.
> 
> Thanks,
> Regards
> JB
> 
> On 08/14/2012 07:54 PM, uromahn wrote:
>> Hi JB,
>>
>> thank you so much for this quick response.
>>
>> We are primarily interested in 2.2.9 - 2.3.0 would only be our second
>> best
>> option for now, and hence this is excellent news.
>>
>> By the way, if it comes to a release vote, it would be a +1 from me.
>>
>> Not that I really have a vote, but we have used and tested 2.2.9-SNAPSHOT
>> for a few weeks now (I have created our own local daily snapshots from
>> the
>> Apache SVN) and could not see any issues with any of our use cases.
>>
>> -Uli
>>
>>
>>
>> -- 
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Tentative-Release-Dates-for-2-2-9-and-or-2-3-0-tp4025591p4025593.html
>>
>> Sent from the Karaf - Dev mailing list archive at Nabble.com.
>>
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Telling whether startup is really complete

2012-08-10 Thread Christoph Gritschenberger

Hi,

Seems I started a somehow more fundamental discussion here about whether
karaf-startup should be delayed at all.

As far as I can tell now there seems to be some common ground now.
Ioannis summed it up pretty good: Providing some method of configuring
startup-delays OK. That's also what I had in mind.

I actually don't have a strong opinion about what should be karaf
default. There are valid points on both sides. I personally have no
problem with the "Press Enter"-approach but that's just me.
The progress bar looks a bit odd, because it may revert to less progress
when new bundles are installed by e.g. the features-installer.

kind regards,
christoph

On 09/08/12 21:09, Achim Nierbeck wrote:
> Christian,
> 
> I'm sorry but I don't see any agreement on delay beeing the better
> option, or beeing the default.
> If you think it's ok to have the delay for your customers I'm fine if
> you apply it to your custom distribution.
> I'm also fine with opening a way to tell the shell how long it should
> wait. I'm also fine to keep the "locked" shell
> in Karaf for people to use for their own distribution.
> So I'm +1 for the sum-up of Ioannis.
> 
> @Johan
> how about a "Karaf started in MM:SS" in log :-D
> 
> regards, Achim
> 
> 2012/8/9 Christian Schneider :
>> I mostly agree besides for the default. I think we all agree that the
>> delayed start of the console is the better option for beginners while
>> a lot of karaf developers like the console that starts directly.
>>
>> For this reason I think we should have the delayed start as default for two
>> reasons:
>> 1. We are only a handfull of developers while there are thousands of users
>> and most are beginners or at least do not have a deep understanding of
>> karaf.
>> 2. The delayed start is a nice out of the box experience for people who
>> start karaf for the first time. Especially the beginners will not find the
>> option to turn this on easily
>>
>> Christian
>>
>> Am 09.08.2012 19:40, schrieb Ioannis Canellos:
>>
>>> I've read a lot of interesting opinions and I'd like to share mine:
>>>
>>> i) The Karaf shell should start asap, unless explicitly configured. The
>>> enter thing is nice but should be optional imho.
>>> ii) Determining when Karaf is started is one thing, determining when an
>>> application is started is another.
>>> iii) A log entry that says Karaf has started sounds enough, we can
>>> optionally provide that info through the info command.
>>> iv) Different users have different needs on what started means. To cover
>>> all cases we could allow the user to use a configuration file that will
>>> contain requirements (package, service etc) and have everyone configure it
>>> however he wishes.
>>>
>>
>>
>> --
>>  Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
> 
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Telling whether startup is really complete

2012-08-09 Thread Christoph Gritschenberger

ph, such a good
>>>> idea). Consider that we register those ReadyServices via the activator
>>>> they will be available once the bundle is active; once all framework
>>>> bundles are active the feature service can state once he had installed
>>>> all features, the deployer can state once all bundles from the deploy
>>>> folder had been added, a custom application bundle can e.g. check if a
>>>> specific url could be reached and so on; This could finally provide a
>>>> "suite" which could be adapted to give a user a quite accurate "real"
>>>> start-point (even if it requires some manual adaption). I'm really
>>>> interested what you think about this once you've given it a little bit
>>>> more time for consideration :-)
>>>>
>>>>> However I'm agree about the featuresBoot (AFAIR we have a Jira about
>>>> that).
>>>>> I will take time deeper later (time to go dinner for me here ;)).
>>>> Dinner? Wow, I really should take more time keeping up-to-date; where
>>>> the hell are you :-)
>>>>
>>>> Kind regards,
>>>> Andreas
>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/09/2012 05:08 AM, Andreas Pieber wrote:
>>>>>> Hey guys,
>>>>>>
>>>>>> While the 2.3.x code looks ways more stable than the one on the
>>>>>> master
>>>>>> I'm not convinced that it will solve Christoph's problem. As
>>>>>> Christoph
>>>>>> pointed out:
>>>>>>
>>>>>> "There is a short delay between the point where all
>>>>>> karaf-base-bundles
>>>>>> are loaded and the feature-installer starts installing features
>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>> almost always happens"
>>>>>>
>>>>>> I would say the relevant parts in Karaf 2.3.x are:
>>>>>>
>>>>>> a) StartupListener.java
>>>>>> b) DelayedStarted.java
>>>>>>
>>>>>> So, If I'm correct (a) is printing the number of active
>>>>>> bundles/available bundles till (b) set a constant which will occur
>>>>>> the
>>>>>> moment a bundle is added with a start lvl higher than
>>>>>> "org.osgi.framework.startlevel.beginning". That's basically fine, but
>>>>>> this will still not fix the problem with the feature service adding
>>>>>> bundles (with even higher start lvls) AFTER the framework startup. In
>>>>>> addition we've the "old" problem of various parts (blueprint,
>>>>>> webapps,
>>>>>> deployer, ...) starting up async. While most of those components know
>>>>>> when they're finished (a) cannot know. This has the advantage that it
>>>>>> has no problem if a bundle is e.g. caught in a startup loop, but on
>>>>>> the other hand you wont know when all bundles are active. In addition
>>>>>> it will show the framework ready although bundles with a startup lvl
>>>>>> higher than "org.osgi.framework.startlevel.beginning" are still
>>>>>> starting.
>>>>>>
>>>>>> Therefore I'm curious if the process shouldn't be something like
>>>>>>
>>>>>> a) wait till all bundles are active or one have failed
>>>>>> b) once all bundles are active query for a StartupIndicator service
>>>>>> and wait till all of them either return finished or failed
>>>>>> c) once all startup indicators are finished wait again till all
>>>>>> (possibly new bundles) are active
>>>>>> d) now there are maybe new StartupIndicators available or everything
>>>>>> is up and running
>>>>>>
>>>>>> Do I miss anything? WDYT?
>>>>>>
>>>>>> Kind regards,
>>>>>> Andreas
>>>>>>
>>>>>> On Wed, Aug 8, 2012 at 9:55 PM, Jean-Baptiste Onofré
>>>>>> 
>>>>>> wrote:
>>>>>>> Hi Christoph,
>>>>>>>
>>>>>>> FYI, we made some enhancement in karaf-2.3.x and trunk. Now you
>>>>>>> have a
>>>>>>> progress bar while Karaf is starting and the shell console
>>>>>>> arrives only
>>>>>>> when
>>>>>>> the startup is complete.
>>>>>>>
>>>>>>> I invite you to take a look on that.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 08/08/2012 08:43 PM, Christoph Gritschenberger wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I had another meeting with a customer today who asked me: "How
>>>>>>>> can I
>>>>>>>> tell whether it is started up completely?". ("It" being our
>>>> karaf-based
>>>>>>>> product)
>>>>>>>>
>>>>>>>> So I had a look at several alternatives how I could accomplish this
>>>> and
>>>>>>>> had an idea I wanted to discuss.
>>>>>>>>
>>>>>>>> I know that I can modify the Start-level of the Shell-bundle but I
>>>> don't
>>>>>>>> think that's enough.
>>>>>>>> Recently Christian Schneider implemented something to delay the
>>>> startup
>>>>>>>> of the shell until all bundles are active. I think that's a good
>>>> start,
>>>>>>>> but does not solve the problem completely for me. I encountered
>>>> several
>>>>>>>> issues with the approach:
>>>>>>>>
>>>>>>>> 1. There is a short delay between the point where all
>>>> karaf-base-bundles
>>>>>>>> are loaded and the feature-installer starts installing features
>>>>>>>> specified in "featuresBoot". When starting up the first time, this
>>>>>>>> almost always happens
>>>>>>>>
>>>>>>>> ...
>>>>>>>>   [  45] [Active] [5] OPS4J Base - Lang (1.3.0)
>>>>>>>>   [  46] [
>>>
>>>
>>> -- 
>>> 
>>> Guillaume Nodet
>>> 
>>> Blog: http://gnodet.blogspot.com/
>>> 
>>> FuseSource, Integration everywhere
>>> http://fusesource.com
> 
> 




smime.p7s
Description: S/MIME Cryptographic Signature

Telling whether startup is really complete

2012-08-08 Thread Christoph Gritschenberger

Hi,

I had another meeting with a customer today who asked me: "How can I
tell whether it is started up completely?". ("It" being our karaf-based
product)

So I had a look at several alternatives how I could accomplish this and
had an idea I wanted to discuss.

I know that I can modify the Start-level of the Shell-bundle but I don't
think that's enough.
Recently Christian Schneider implemented something to delay the startup
of the shell until all bundles are active. I think that's a good start,
but does not solve the problem completely for me. I encountered several
issues with the approach:

1. There is a short delay between the point where all karaf-base-bundles
are loaded and the feature-installer starts installing features
specified in "featuresBoot". When starting up the first time, this
almost always happens

...
[  45] [Active] [5] OPS4J Base - Lang (1.3.0)
[  46] [  Resolved] [   20] Apache Aries Blueprint Core Compatiblity
Fragment Bundle (1.0.0), Hosts: 26
[  47] [Active] [   30] Apache Karaf :: System :: Shell Commands
(3.0.0.SNAPSHOT)
[  48] [Active] [   24] Apache Karaf :: Deployer :: Spring
(3.0.0.SNAPSHOT)
karaf@root()>

After a few seconds the installing of the features commences:

...
[  47] [Active] [   30] Apache Karaf :: System :: Shell Commands
(3.0.0.SNAPSHOT)
[  48] [Active] [   24] Apache Karaf :: Deployer :: Spring
(3.0.0.SNAPSHOT)
[  49] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Core
(3.0.0.SNAPSHOT)
[  50] [ Installed] [   30] Apache Karaf :: ConfigAdmin :: Commands
(3.0.0.SNAPSHOT)
...

So the condition "all non-fragment bundles are ACTIVE" does not
necessarily mean "startup is complete".

2. Even if all features are installed completely and all bundles are
ACTIVE, they may contain a blueprint-file and the blueprint-container
might take even longer to start up.


So I had an idea, I wanted to discuss:
How about introducing an additional interface (like "StartupIndicator"
with a method "boolean isStartupComplete()" or "int
getStartupProgress()"). The FeatureService could implement this
interface and provide the Service be registered with this additional
interface.
The Shell-bundle could then pick up all "StartupIndicator"-services and
require all of them to return true before actually showing the prompt.
Another StartupIndicator could check for BlueprintContainers to be
available.

This way, the shell would not actually have a direct dependency to the
FeatureService, but could delay the prompt until all features are
installed and active.

Another advantage is, that users would be able to implement their own
"StartupIndicator"-services to introduce even more delays.

WDYT?

kind regards,
christoph



smime.p7s
Description: S/MIME Cryptographic Signature

43 matches

Mail list logo