You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com> on 2012/10/03 19:28:49 UTC
[DS] Feedback wanted on some ideas
I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
boolean tasksCompleted();
void waitForTasksCompleted();
on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
thanks
david jencks
Re: [DS] Feedback wanted on some ideas
Posted by Andrei Pozolotin <an...@gmail.com>.
-------- Original Message --------
Subject: [DS] Feedback wanted on some ideas
From: David Jencks <da...@yahoo.com>
To: dev@felix.apache.org
Date: Wed 03 Oct 2012 12:28:49 PM CDT
> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>
yes, as a dumb user :-) I have hard time understanding both old and new
state transitions.
would it be possible to produce proposed scr state diagram in a form
similar to this:
http://devangelist.blogspot.com/2011/04/osgi-bundle-lifecycles.html
Re: [DS] Feedback wanted on some ideas
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 12.10.2012 um 02:29 schrieb David Jencks:
>
> On Oct 5, 2012, at 12:35 PM, Felix Meschberger wrote:
>
>> Hi,
>>
>> Am 03.10.2012 um 19:28 schrieb David Jencks:
>>
>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>
>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>
>>> boolean tasksCompleted();
>>>
>>> void waitForTasksCompleted();
>>>
>>>
>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>
>> -1
>>
>> I think such information is without any value. And our own tests being the sole use cases is a bit weak to add API.
>
> The use cases I have are:
>
> 1. shutdown. We want to make sure the queue is empty before turning off logging. (FELIX-3704)
This does not need new external API. I think the actor's terminate method can do this before adding the "Terminator" task.
> 2. You might want to install a lot of application deployer components and make sure they are all fully started before starting say a file listener that looks for applications to deploy. If some of the first set of components are enabled through code, it's hard to tell if they are all completely started without knowing exactly what they are. Similarly you might want to know if a server is "fully started", i.e. all the components that are enabled have at least tried to activate.
This pretty much sounds like YAGNI.
>
> I'm not 100% sure this is a good idea, but I think it could have some use.
Ok, then lets not do it right now.
>
>>
>>>
>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>
>> If I understand the issue/patch correctly, it does something like this: If an optional service cannot be eagerly bound (to call a bind method taking the service instance) due to a circularity (exception thrown from the BundleContext.getService method) it will not be bound but may later be bound if the actual service instance is created. Correct ?
>>
>> I think, this sounds good.
>
> OK, I'll commit it.
>>
>>>
>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>
>> Does FELIX-3557 really imply a spec change ? At most it might be kind of an implementation hint.
>
> If you don't think it needs a spec change I won't worry.
>
>>
>>>
>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>
>> The longer I think about it, the more I have to admit that I agree....
>
> I'm going to change this now because it will make some refactoring easier. If people don't like it we can change back after I'm done.
We should cut a release before refactoring ... A release is long overdue and has been prevented by work around concurrency issues.
Regards
Felix
>
>>
>>>
>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable.
>>
>> Well, these objects have been quite simple and easy to understand and worked perfectly (admittedly with some glitches). Now over time and patches applied, I agree they became quite complex and the concurrency behaviour became more complex. So for concurrency having immutable objects is a lot easier to handle than mutable ones.
>>
>>> The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>
>> I agree, that the states enabled and disabled might be confusing. But I am not sure, whether those are really states of component instances (or component configurations as the spec calls them). Rather they are states of the "abstract" component.
>>
>> The component instances on the other hand have states like unsatisfied, activating, active, registered, etc.
>>
>> In our implementation the component instance is represented by the AbstractComponentManager and its extensions while the "abstract" component is represented by combination of the ComponentHolder and the ComponentMetadata.
>
> I'm going to think about this some more and try some experiments.
>
> thanks for the comments!
> david jencks
>
>>
>> Regards
>> Felix
>
Re: [DS] Feedback wanted on some ideas
Posted by David Jencks <da...@yahoo.com>.
On Oct 5, 2012, at 12:35 PM, Felix Meschberger wrote:
> Hi,
>
> Am 03.10.2012 um 19:28 schrieb David Jencks:
>
>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>
>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>
>> boolean tasksCompleted();
>>
>> void waitForTasksCompleted();
>>
>>
>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>
> -1
>
> I think such information is without any value. And our own tests being the sole use cases is a bit weak to add API.
The use cases I have are:
1. shutdown. We want to make sure the queue is empty before turning off logging. (FELIX-3704)
2. You might want to install a lot of application deployer components and make sure they are all fully started before starting say a file listener that looks for applications to deploy. If some of the first set of components are enabled through code, it's hard to tell if they are all completely started without knowing exactly what they are. Similarly you might want to know if a server is "fully started", i.e. all the components that are enabled have at least tried to activate.
I'm not 100% sure this is a good idea, but I think it could have some use.
>
>>
>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>
> If I understand the issue/patch correctly, it does something like this: If an optional service cannot be eagerly bound (to call a bind method taking the service instance) due to a circularity (exception thrown from the BundleContext.getService method) it will not be bound but may later be bound if the actual service instance is created. Correct ?
>
> I think, this sounds good.
OK, I'll commit it.
>
>>
>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>
> Does FELIX-3557 really imply a spec change ? At most it might be kind of an implementation hint.
If you don't think it needs a spec change I won't worry.
>
>>
>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>
> The longer I think about it, the more I have to admit that I agree....
I'm going to change this now because it will make some refactoring easier. If people don't like it we can change back after I'm done.
>
>>
>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable.
>
> Well, these objects have been quite simple and easy to understand and worked perfectly (admittedly with some glitches). Now over time and patches applied, I agree they became quite complex and the concurrency behaviour became more complex. So for concurrency having immutable objects is a lot easier to handle than mutable ones.
>
>> The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>
> I agree, that the states enabled and disabled might be confusing. But I am not sure, whether those are really states of component instances (or component configurations as the spec calls them). Rather they are states of the "abstract" component.
>
> The component instances on the other hand have states like unsatisfied, activating, active, registered, etc.
>
> In our implementation the component instance is represented by the AbstractComponentManager and its extensions while the "abstract" component is represented by combination of the ComponentHolder and the ComponentMetadata.
I'm going to think about this some more and try some experiments.
thanks for the comments!
david jencks
>
> Regards
> Felix
Re: [DS] Feedback wanted on some ideas
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 03.10.2012 um 19:28 schrieb David Jencks:
> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>
> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>
> boolean tasksCompleted();
>
> void waitForTasksCompleted();
>
>
> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
-1
I think such information is without any value. And our own tests being the sole use cases is a bit weak to add API.
>
> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
If I understand the issue/patch correctly, it does something like this: If an optional service cannot be eagerly bound (to call a bind method taking the service instance) due to a circularity (exception thrown from the BundleContext.getService method) it will not be bound but may later be bound if the actual service instance is created. Correct ?
I think, this sounds good.
>
> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
Does FELIX-3557 really imply a spec change ? At most it might be kind of an implementation hint.
>
> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
The longer I think about it, the more I have to admit that I agree....
>
> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable.
Well, these objects have been quite simple and easy to understand and worked perfectly (admittedly with some glitches). Now over time and patches applied, I agree they became quite complex and the concurrency behaviour became more complex. So for concurrency having immutable objects is a lot easier to handle than mutable ones.
> The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
I agree, that the states enabled and disabled might be confusing. But I am not sure, whether those are really states of component instances (or component configurations as the spec calls them). Rather they are states of the "abstract" component.
The component instances on the other hand have states like unsatisfied, activating, active, registered, etc.
In our implementation the component instance is represented by the AbstractComponentManager and its extensions while the "abstract" component is represented by combination of the ComponentHolder and the ComponentMetadata.
Regards
Felix
Re: [DS] Feedback wanted on some ideas
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Andrei,
Am 05.10.2012 um 21:19 schrieb Andrei Pozolotin:
> David:
>
> in case you are open for more revolutionary ideas:
> can we have "DS/SCR annotation service", please? :-)
We have annotations. But those are build-time annotations for a good reason: We don't want to eagerly read/load classes just to find annotations. Rather the annotations are converted into the traditional descriptors which provide for great support of lazy loading.
So, I don't really see a benefit in runtime annotations.
Regards
Felix
>
> just steal from Aries:
>
> http://aries.apache.org/modules/blueprintannotation.html
>
> """
> Blueprint annotation is being prototyped in Apache Aries in trunk/blueprint.
> The blueprint annotation service is an optional service to the blueprint core
> and should not affect the blueprint core if annotation supported is not
> required. If the blueprint annotation service is available, the bundle contains
> no blueprint definition XML and the bundle contains the manifest header
> Bundle-Blueprint-Annotation with the value set to true, the blueprint
> annotation service will attempt to scan the bundle for blueprint annotations,
> such as @Blueprint, @Bean, @Service, @Reference, @ReferenceList, etc. The
> blueprint annotation api is available in
> trunk/blueprint/blueprint-annotation-api module, while the blueprint
> implementation is available in trunk/blueprint/blueprint-annotatiom-impl
> module. A blueprint annotated sample is also provided in
> trunk/blueprint/blueprint-sample-annotation.
> """
>
> thank you.
>
> Andrei.
>
> -------- Original Message --------
> Subject: Re: [DS] Feedback wanted on some ideas
> From: David Jencks <da...@yahoo.com>
> To: dev@felix.apache.org
> Date: Fri 05 Oct 2012 12:26:40 PM CDT
>> Any comments on these ideas? Should I take silence as agreement :-) ?
>>
>> thanks
>> david jencks
>>
>> On Oct 3, 2012, at 10:28 AM, David Jencks wrote:
>>
>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>
>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>
>>> boolean tasksCompleted();
>>>
>>> void waitForTasksCompleted();
>>>
>>>
>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>
>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>
>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>
>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>
>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>
>
Re: [DS] Feedback wanted on some ideas
Posted by Andrei Pozolotin <an...@gmail.com>.
David:
in case you are open for more revolutionary ideas:
can we have "DS/SCR annotation service", please? :-)
just steal from Aries:
http://aries.apache.org/modules/blueprintannotation.html
"""
Blueprint annotation is being prototyped in Apache Aries in trunk/blueprint.
The blueprint annotation service is an optional service to the blueprint core
and should not affect the blueprint core if annotation supported is not
required. If the blueprint annotation service is available, the bundle contains
no blueprint definition XML and the bundle contains the manifest header
Bundle-Blueprint-Annotation with the value set to true, the blueprint
annotation service will attempt to scan the bundle for blueprint annotations,
such as @Blueprint, @Bean, @Service, @Reference, @ReferenceList, etc. The
blueprint annotation api is available in
trunk/blueprint/blueprint-annotation-api module, while the blueprint
implementation is available in trunk/blueprint/blueprint-annotatiom-impl
module. A blueprint annotated sample is also provided in
trunk/blueprint/blueprint-sample-annotation.
"""
thank you.
Andrei.
-------- Original Message --------
Subject: Re: [DS] Feedback wanted on some ideas
From: David Jencks <da...@yahoo.com>
To: dev@felix.apache.org
Date: Fri 05 Oct 2012 12:26:40 PM CDT
> Any comments on these ideas? Should I take silence as agreement :-) ?
>
> thanks
> david jencks
>
> On Oct 3, 2012, at 10:28 AM, David Jencks wrote:
>
>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>
>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>
>> boolean tasksCompleted();
>>
>> void waitForTasksCompleted();
>>
>>
>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>
>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>
>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>
>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>
>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>
>>
>> thanks
>> david jencks
>>
>>
>
Re: [DS] Feedback wanted on some ideas
Posted by David Jencks <da...@yahoo.com>.
Any comments on these ideas? Should I take silence as agreement :-) ?
thanks
david jencks
On Oct 3, 2012, at 10:28 AM, David Jencks wrote:
> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>
> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>
> boolean tasksCompleted();
>
> void waitForTasksCompleted();
>
>
> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>
> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>
> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>
> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>
> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>
>
> thanks
> david jencks
>
>
Re: [DS] Feedback wanted on some ideas
Posted by David Jencks <da...@yahoo.com>.
In felix ds you can use the ScrService to enable or disable any component no matter what bundle it is in. So I don't think adding another non-spec way to do this is a good idea.
With regard to the configuration ;pd/factory pid I'm not an expert but I think there were some R4.3 changes in how configurationPIDs might be sharable, but I thought previously the first bundle to consume a configurationPID got to use it exclusively.
Also in DS 1.2 you can specify the configurationPID separately from the component name.
david jencks
On Oct 3, 2012, at 11:31 AM, Andrei Pozolotin wrote:
> I do not know.
>
> how is this addressed by ConfigurationAdmin?
> service.pid and factory.pid are supposed to be framework-global? how one
> bundle is creating a config entry for another?
> DS component.name with configurationPolicy=required is mapped to
> ConfigurationAdmin service.pid/factory.pid - means it is already global?
>
> -------- Original Message --------
> Subject: Re: [DS] Feedback wanted on some ideas
> From: David Jencks <da...@yahoo.com>
> To: dev@felix.apache.org
> Date: Wed 03 Oct 2012 12:49:24 PM CDT
>> As of DS 1.1, the component name is only unique per bundle. So I'm not sure how this would work, wouldn't you need to include the bundle in the method signature?
>>
>> david jencks
>>
>> On Oct 3, 2012, at 10:39 AM, Andrei Pozolotin wrote:
>>
>>> great ideas; one more for your consideration
>>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>>> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
>>> """
>>>
>>> public void *enableComponent*(java.lang.String name)
>>>
>>> Enables the specified component name. The specified component name
>>> must be in the same bundle as this component.
>>>
>>> """
>>>
>>> instead, I suggest to permit traversal of bundle boundaries, so
>>> enable/disable target can be anywhere.
>>>
>>> -------- Original Message --------
>>> Subject: [DS] Feedback wanted on some ideas
>>> From: David Jencks <da...@yahoo.com>
>>> To: dev@felix.apache.org
>>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>>
>>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>>
>>>> boolean tasksCompleted();
>>>>
>>>> void waitForTasksCompleted();
>>>>
>>>>
>>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>>
>>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>>
>>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>>
>>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>>
>>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>>
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>
>
Re: [DS] Feedback wanted on some ideas
Posted by Andrei Pozolotin <an...@gmail.com>.
I do not know.
how is this addressed by ConfigurationAdmin?
service.pid and factory.pid are supposed to be framework-global? how one
bundle is creating a config entry for another?
DS component.name with configurationPolicy=required is mapped to
ConfigurationAdmin service.pid/factory.pid - means it is already global?
-------- Original Message --------
Subject: Re: [DS] Feedback wanted on some ideas
From: David Jencks <da...@yahoo.com>
To: dev@felix.apache.org
Date: Wed 03 Oct 2012 12:49:24 PM CDT
> As of DS 1.1, the component name is only unique per bundle. So I'm not sure how this would work, wouldn't you need to include the bundle in the method signature?
>
> david jencks
>
> On Oct 3, 2012, at 10:39 AM, Andrei Pozolotin wrote:
>
>> great ideas; one more for your consideration
>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
>> """
>>
>> public void *enableComponent*(java.lang.String name)
>>
>> Enables the specified component name. The specified component name
>> must be in the same bundle as this component.
>>
>> """
>>
>> instead, I suggest to permit traversal of bundle boundaries, so
>> enable/disable target can be anywhere.
>>
>> -------- Original Message --------
>> Subject: [DS] Feedback wanted on some ideas
>> From: David Jencks <da...@yahoo.com>
>> To: dev@felix.apache.org
>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>
>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>
>>> boolean tasksCompleted();
>>>
>>> void waitForTasksCompleted();
>>>
>>>
>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>
>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>
>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>
>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>
>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>
Re: [DS] Feedback wanted on some ideas
Posted by David Jencks <da...@yahoo.com>.
As of DS 1.1, the component name is only unique per bundle. So I'm not sure how this would work, wouldn't you need to include the bundle in the method signature?
david jencks
On Oct 3, 2012, at 10:39 AM, Andrei Pozolotin wrote:
> great ideas; one more for your consideration
> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
> """
>
> public void *enableComponent*(java.lang.String name)
>
> Enables the specified component name. The specified component name
> must be in the same bundle as this component.
>
> """
>
> instead, I suggest to permit traversal of bundle boundaries, so
> enable/disable target can be anywhere.
>
> -------- Original Message --------
> Subject: [DS] Feedback wanted on some ideas
> From: David Jencks <da...@yahoo.com>
> To: dev@felix.apache.org
> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>
>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>
>> boolean tasksCompleted();
>>
>> void waitForTasksCompleted();
>>
>>
>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>
>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>
>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>
>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>
>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>
>>
>> thanks
>> david jencks
>>
>>
>>
>
Re: java 7 osgi core & compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Awesome,
thanks a lot, I will update in Karaf.
Regards
JB
On 11/05/2012 08:13 PM, David Bosschaert wrote:
> I've released them to central now:
> http://search.maven.org/#artifactdetails%7Corg.osgi%7Corg.osgi.core%7C4.3.1%7Cjar
>
> http://search.maven.org/#artifactdetails%7Corg.osgi%7Corg.osgi.compendium%7C4.3.1%7Cjar
>
> Cheers,
>
> David
>
> On 5 November 2012 11:57, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>> Hi David,
>>
>> I tested these artifacts on Karaf trunk without problem. The signatures look
>> good as well.
>>
>> You have my +1 to promote it to Central.
>>
>> Thanks,
>>
>> 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 <an...@gmail.com>
>>> 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 <da...@gmail.com>
>>>> To: dev@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 <an...@gmail.com>
>>>> 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
>>>>
>>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by David Bosschaert <da...@gmail.com>.
I've released them to central now:
http://search.maven.org/#artifactdetails%7Corg.osgi%7Corg.osgi.core%7C4.3.1%7Cjar
http://search.maven.org/#artifactdetails%7Corg.osgi%7Corg.osgi.compendium%7C4.3.1%7Cjar
Cheers,
David
On 5 November 2012 11:57, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi David,
>
> I tested these artifacts on Karaf trunk without problem. The signatures look
> good as well.
>
> You have my +1 to promote it to Central.
>
> Thanks,
>
> 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 <an...@gmail.com>
>> 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 <da...@gmail.com>
>>> To: dev@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 <an...@gmail.com>
>>> 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
>>>
>>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi David,
I tested these artifacts on Karaf trunk without problem. The signatures
look good as well.
You have my +1 to promote it to Central.
Thanks,
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 <an...@gmail.com> 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 <da...@gmail.com>
>> To: dev@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 <an...@gmail.com>
>> 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
>>
>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
my motivation for this is not to release "versions side by side", but to
ease migration and related testing
-------- Original Message --------
Subject: Re: java 7 osgi core & compendium
From: Andreas Pieber <an...@gmail.com>
To: Apache Karaf <de...@karaf.apache.org>
Date: Thu 01 Nov 2012 01:30:48 PM CDT
> I'm not quite sure about that part... why do we want to add the artifactIds
> as properties? a) they wont change that much b) we do not really want to
> release karaf versions for multible core/compendium versions side by side.
>
> Just my 0.02€
>
> Kind regards,
> Andreas
>
>
> On Thu, Nov 1, 2012 at 6:05 PM, Andrei Pozolotin <andrei.pozolotin@gmail.com
>> wrote:
>> JB: great, thank you!
>>
>> also:
>>
>> since migration to R5 will probably be as painful as this one, I suggest
>> to have more properties, such as
>>
>> <osgi.groupId>org.osgi</osgi.groupId>
>> <osgi.core.version>4.3.1</osgi.core.version>
>> <osgi.compendium.version>4.3.1</osgi.compendium.version>
>> <osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
>>
>>
>> <osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
>>
>> and to make switch between osgi releases controlled via maven profile(s)
>>
>> -------- Original Message --------
>> Subject: Re: java 7 osgi core & compendium
>> From: Jean-Baptiste Onofré <jb...@nanthrax.net>
>> To: Andrei Pozolotin <an...@gmail.com>
>> Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
>> Date: Thu 01 Nov 2012 11:51:51 AM CDT
>>> Hi,
>>>
>>> I will work on it tonight.
>>> I keep you posted.
>>>
>>> Regards
>>> JB
>>>
>>> On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
>>>> To: dev@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
>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>> To: dev@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
>>>>>>> <an...@gmail.com>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>
Re: java 7 osgi core & compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
Indeed this would be a bit more effort but I hope the spec jars will
work in the future.
Building the jars ourself was hopefully an exemption.
Christian
Am 01.11.2012 20:55, schrieb Andrei Pozolotin:
> what will you do if you need to play with experimental/self-built osgi
> jars again?
>
> at seems at least groupId needs be a parameter;
>
> -------- Original Message --------
> Subject: Re: java 7 osgi core & compendium
> From: Christian Schneider <ch...@die-schneider.net>
> To: dev@karaf.apache.org
> Date: Thu 01 Nov 2012 02:50:30 PM CDT
>> +1
>>
>> Let´s keep the groupId and artifactId static.
>>
>> Christian
>>
>> Am 01.11.2012 19:30, schrieb Andreas Pieber:
>>> I'm not quite sure about that part... why do we want to add the
>>> artifactIds
>>> as properties? a) they wont change that much b) we do not really
>>> want to
>>> release karaf versions for multible core/compendium versions side by
>>> side.
>>>
>>> Just my 0.02€
>>>
>>> Kind regards,
>>> Andreas
>>>
>>>
>>> On Thu, Nov 1, 2012 at 6:05 PM, Andrei Pozolotin
>>> <andrei.pozolotin@gmail.com
>>>> wrote:
>>>> JB: great, thank you!
>>>>
>>>> also:
>>>>
>>>> since migration to R5 will probably be as painful as this one, I
>>>> suggest
>>>> to have more properties, such as
>>>>
>>>> <osgi.groupId>org.osgi</osgi.groupId>
>>>> <osgi.core.version>4.3.1</osgi.core.version>
>>>> <osgi.compendium.version>4.3.1</osgi.compendium.version>
>>>> <osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
>>>>
>>>>
>>>> <osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
>>>>
>>>>
>>>> and to make switch between osgi releases controlled via maven
>>>> profile(s)
>>>>
>>>> -------- Original Message --------
>>>> Subject: Re: java 7 osgi core & compendium
>>>> From: Jean-Baptiste Onofré <jb...@nanthrax.net>
>>>> To: Andrei Pozolotin <an...@gmail.com>
>>>> Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
>>>> Date: Thu 01 Nov 2012 11:51:51 AM CDT
>>>>> Hi,
>>>>>
>>>>> I will work on it tonight.
>>>>> I keep you posted.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
>>>>>> To: dev@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
>>>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>>>> To: dev@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
>>>>>>>>> <an...@gmail.com>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>
>>
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Divisionhttp://www.talend.com
Re: java 7 osgi core & compendium
Posted by Andreas Pieber <an...@gmail.com>.
Using a little python "replaceall" script :-)
Sorry, I don't mean to offer any offence by this. I just think that this
changes are really, really seldom and would not justify the change in
structure.
Kind regards,
Andreas
On Nov 1, 2012 8:56 PM, "Andrei Pozolotin" <an...@gmail.com>
wrote:
> what will you do if you need to play with experimental/self-built osgi
> jars again?
>
> at seems at least groupId needs be a parameter;
>
> -------- Original Message --------
> Subject: Re: java 7 osgi core & compendium
> From: Christian Schneider <ch...@die-schneider.net>
> To: dev@karaf.apache.org
> Date: Thu 01 Nov 2012 02:50:30 PM CDT
> > +1
> >
> > Let´s keep the groupId and artifactId static.
> >
> > Christian
> >
> > Am 01.11.2012 19:30, schrieb Andreas Pieber:
> >> I'm not quite sure about that part... why do we want to add the
> >> artifactIds
> >> as properties? a) they wont change that much b) we do not really want to
> >> release karaf versions for multible core/compendium versions side by
> >> side.
> >>
> >> Just my 0.02€
> >>
> >> Kind regards,
> >> Andreas
> >>
> >>
> >> On Thu, Nov 1, 2012 at 6:05 PM, Andrei Pozolotin
> >> <andrei.pozolotin@gmail.com
> >>> wrote:
> >>> JB: great, thank you!
> >>>
> >>> also:
> >>>
> >>> since migration to R5 will probably be as painful as this one, I
> >>> suggest
> >>> to have more properties, such as
> >>>
> >>> <osgi.groupId>org.osgi</osgi.groupId>
> >>> <osgi.core.version>4.3.1</osgi.core.version>
> >>> <osgi.compendium.version>4.3.1</osgi.compendium.version>
> >>> <osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
> >>>
> >>>
> >>>
> <osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
> >>>
> >>>
> >>> and to make switch between osgi releases controlled via maven
> >>> profile(s)
> >>>
> >>> -------- Original Message --------
> >>> Subject: Re: java 7 osgi core & compendium
> >>> From: Jean-Baptiste Onofré <jb...@nanthrax.net>
> >>> To: Andrei Pozolotin <an...@gmail.com>
> >>> Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
> >>> Date: Thu 01 Nov 2012 11:51:51 AM CDT
> >>>> Hi,
> >>>>
> >>>> I will work on it tonight.
> >>>> I keep you posted.
> >>>>
> >>>> Regards
> >>>> JB
> >>>>
> >>>> On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
> >>>>> To: dev@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
> >>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
> >>>>>>>> To: dev@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
> >>>>>>>> <an...@gmail.com>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>>>
> >>>
> >
> >
>
>
Re: java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
what will you do if you need to play with experimental/self-built osgi
jars again?
at seems at least groupId needs be a parameter;
-------- Original Message --------
Subject: Re: java 7 osgi core & compendium
From: Christian Schneider <ch...@die-schneider.net>
To: dev@karaf.apache.org
Date: Thu 01 Nov 2012 02:50:30 PM CDT
> +1
>
> Let´s keep the groupId and artifactId static.
>
> Christian
>
> Am 01.11.2012 19:30, schrieb Andreas Pieber:
>> I'm not quite sure about that part... why do we want to add the
>> artifactIds
>> as properties? a) they wont change that much b) we do not really want to
>> release karaf versions for multible core/compendium versions side by
>> side.
>>
>> Just my 0.02€
>>
>> Kind regards,
>> Andreas
>>
>>
>> On Thu, Nov 1, 2012 at 6:05 PM, Andrei Pozolotin
>> <andrei.pozolotin@gmail.com
>>> wrote:
>>> JB: great, thank you!
>>>
>>> also:
>>>
>>> since migration to R5 will probably be as painful as this one, I
>>> suggest
>>> to have more properties, such as
>>>
>>> <osgi.groupId>org.osgi</osgi.groupId>
>>> <osgi.core.version>4.3.1</osgi.core.version>
>>> <osgi.compendium.version>4.3.1</osgi.compendium.version>
>>> <osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
>>>
>>>
>>> <osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
>>>
>>>
>>> and to make switch between osgi releases controlled via maven
>>> profile(s)
>>>
>>> -------- Original Message --------
>>> Subject: Re: java 7 osgi core & compendium
>>> From: Jean-Baptiste Onofré <jb...@nanthrax.net>
>>> To: Andrei Pozolotin <an...@gmail.com>
>>> Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
>>> Date: Thu 01 Nov 2012 11:51:51 AM CDT
>>>> Hi,
>>>>
>>>> I will work on it tonight.
>>>> I keep you posted.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
>>>>> To: dev@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
>>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>>> To: dev@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
>>>>>>>> <an...@gmail.com>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>
>
>
Re: java 7 osgi core & compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
+1
Let´s keep the groupId and artifactId static.
Christian
Am 01.11.2012 19:30, schrieb Andreas Pieber:
> I'm not quite sure about that part... why do we want to add the artifactIds
> as properties? a) they wont change that much b) we do not really want to
> release karaf versions for multible core/compendium versions side by side.
>
> Just my 0.02€
>
> Kind regards,
> Andreas
>
>
> On Thu, Nov 1, 2012 at 6:05 PM, Andrei Pozolotin <andrei.pozolotin@gmail.com
>> wrote:
>> JB: great, thank you!
>>
>> also:
>>
>> since migration to R5 will probably be as painful as this one, I suggest
>> to have more properties, such as
>>
>> <osgi.groupId>org.osgi</osgi.groupId>
>> <osgi.core.version>4.3.1</osgi.core.version>
>> <osgi.compendium.version>4.3.1</osgi.compendium.version>
>> <osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
>>
>>
>> <osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
>>
>> and to make switch between osgi releases controlled via maven profile(s)
>>
>> -------- Original Message --------
>> Subject: Re: java 7 osgi core & compendium
>> From: Jean-Baptiste Onofré <jb...@nanthrax.net>
>> To: Andrei Pozolotin <an...@gmail.com>
>> Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
>> Date: Thu 01 Nov 2012 11:51:51 AM CDT
>>> Hi,
>>>
>>> I will work on it tonight.
>>> I keep you posted.
>>>
>>> Regards
>>> JB
>>>
>>> On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
>>>> To: dev@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
>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>> To: dev@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
>>>>>>> <an...@gmail.com>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: java 7 osgi core & compendium
Posted by Andreas Pieber <an...@gmail.com>.
I'm not quite sure about that part... why do we want to add the artifactIds
as properties? a) they wont change that much b) we do not really want to
release karaf versions for multible core/compendium versions side by side.
Just my 0.02€
Kind regards,
Andreas
On Thu, Nov 1, 2012 at 6:05 PM, Andrei Pozolotin <andrei.pozolotin@gmail.com
> wrote:
> JB: great, thank you!
>
> also:
>
> since migration to R5 will probably be as painful as this one, I suggest
> to have more properties, such as
>
> <osgi.groupId>org.osgi</osgi.groupId>
> <osgi.core.version>4.3.1</osgi.core.version>
> <osgi.compendium.version>4.3.1</osgi.compendium.version>
> <osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
>
>
> <osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
>
> and to make switch between osgi releases controlled via maven profile(s)
>
> -------- Original Message --------
> Subject: Re: java 7 osgi core & compendium
> From: Jean-Baptiste Onofré <jb...@nanthrax.net>
> To: Andrei Pozolotin <an...@gmail.com>
> Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
> Date: Thu 01 Nov 2012 11:51:51 AM CDT
> > Hi,
> >
> > I will work on it tonight.
> > I keep you posted.
> >
> > Regards
> > JB
> >
> > On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
> >> To: dev@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
> >>>> <an...@gmail.com> 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 <da...@gmail.com>
> >>>>> To: dev@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
> >>>>> <an...@gmail.com>
> >>>>> 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
> >>>>>
> >>>>>
> >>>
> >>
> >
>
>
Re: java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
JB: great, thank you!
also:
since migration to R5 will probably be as painful as this one, I suggest
to have more properties, such as
<osgi.groupId>org.osgi</osgi.groupId>
<osgi.core.version>4.3.1</osgi.core.version>
<osgi.compendium.version>4.3.1</osgi.compendium.version>
<osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
<osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
and to make switch between osgi releases controlled via maven profile(s)
-------- Original Message --------
Subject: Re: java 7 osgi core & compendium
From: Jean-Baptiste Onofré <jb...@nanthrax.net>
To: Andrei Pozolotin <an...@gmail.com>
Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
Date: Thu 01 Nov 2012 11:51:51 AM CDT
> Hi,
>
> I will work on it tonight.
> I keep you posted.
>
> Regards
> JB
>
> On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
>> To: dev@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
>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>> To: dev@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
>>>>> <an...@gmail.com>
>>>>> 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
>>>>>
>>>>>
>>>
>>
>
Re: java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
JB: great, thank you!
also:
since migration to R5 will probably be as painful as this one, I suggest
to have more properties, such as
<osgi.groupId>org.osgi</osgi.groupId>
<osgi.core.version>4.3.1</osgi.core.version>
<osgi.compendium.version>4.3.1</osgi.compendium.version>
<osgi.core.artifactId>org.osgi.core</osgi.core.artifactId>
<osgi.compendium.artifactId>org.osgi.compendium</osgi.compendium.artifactId>
and to make switch between osgi releases controlled via maven profile(s)
-------- Original Message --------
Subject: Re: java 7 osgi core & compendium
From: Jean-Baptiste Onofré <jb...@nanthrax.net>
To: Andrei Pozolotin <an...@gmail.com>
Cc: Felix Dev <de...@felix.apache.org>, Karaf Dev <de...@karaf.apache.org>
Date: Thu 01 Nov 2012 11:51:51 AM CDT
> Hi,
>
> I will work on it tonight.
> I keep you posted.
>
> Regards
> JB
>
> On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
>> To: dev@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
>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>> To: dev@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
>>>>> <an...@gmail.com>
>>>>> 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
>>>>>
>>>>>
>>>
>>
>
Re: java 7 osgi core & compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I will work on it tonight.
I keep you posted.
Regards
JB
On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
> To: dev@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
>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>> To: dev@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 <an...@gmail.com>
>>>> 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
>>>>
>>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I will work on it tonight.
I keep you posted.
Regards
JB
On 11/01/2012 05:50 PM, 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é <jb...@nanthrax.net>
> To: dev@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
>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>> To: dev@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 <an...@gmail.com>
>>>> 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
>>>>
>>>>
>>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by Christoph Gritschenberger <ch...@gmail.com>.
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é <jb...@nanthrax.net>
>>> To: dev@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
>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>> To: dev@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
>>>>>> <an...@gmail.com>
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>
>>>
>
Re: java 7 osgi core & compendium
Posted by Andreas Pieber <an...@gmail.com>.
Hey Claus,
4.3.0 and 4.3.1 are exactly the same, except for the advantage that 4.3.1
is built for use with java7. That's also the reason why we've upgraded
Karaf to get the entire thing (finally) java7 ready.
Kind regards,
Andreas
On Fri, Nov 9, 2012 at 11:27 AM, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> On Thu, Nov 8, 2012 at 3:03 PM, Christoph Gritschenberger
> <ch...@gmail.com> 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é <jb...@nanthrax.net>
> >>>> To: dev@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
> >>>>>> <an...@gmail.com> 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 <da...@gmail.com>
> >>>>>>> To: dev@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
> >>>>>>> <an...@gmail.com>
> >>>>>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >
> >
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: java 7 osgi core & compendium
Posted by Christoph Gritschenberger <ch...@gmail.com>.
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
> <ch...@gmail.com> 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é <jb...@nanthrax.net>
>>>>> To: dev@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
>>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>>> To: dev@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
>>>>>>>> <an...@gmail.com>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
>
>
Re: java 7 osgi core & compendium
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
On Thu, Nov 8, 2012 at 3:03 PM, Christoph Gritschenberger
<ch...@gmail.com> 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é <jb...@nanthrax.net>
>>>> To: dev@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
>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>> To: dev@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
>>>>>>> <an...@gmail.com>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>
>
>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: java 7 osgi core & compendium
Posted by Christoph Gritschenberger <ch...@gmail.com>.
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é <jb...@nanthrax.net>
>>>>> To: dev@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
>>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>>> To: dev@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
>>>>>>>> <an...@gmail.com>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
Re: java 7 osgi core & compendium
Posted by Christoph Gritschenberger <ch...@gmail.com>.
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é <jb...@nanthrax.net>
>>>>> To: dev@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
>>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>>> To: dev@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
>>>>>>>> <an...@gmail.com>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
Re: java 7 osgi core & compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@nanthrax.net>
>>>> To: dev@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
>>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>>> To: dev@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
>>>>>>> <an...@gmail.com>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by Christoph Gritschenberger <ch...@gmail.com>.
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é <jb...@nanthrax.net>
>>> To: dev@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
>>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>>> To: dev@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
>>>>>> <an...@gmail.com>
>>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>
>>>
>
Re: java 7 osgi core & compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é <jb...@nanthrax.net>
>> To: dev@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
>>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>>> To: dev@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 <an...@gmail.com>
>>>>> 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
>>>>>
>>>>>
>>>
>>
>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by Christoph Gritschenberger <ch...@gmail.com>.
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é <jb...@nanthrax.net>
> To: dev@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
>>> <an...@gmail.com> 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 <da...@gmail.com>
>>>> To: dev@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 <an...@gmail.com>
>>>> 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
>>>>
>>>>
>>
>
>
Re: java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
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é <jb...@nanthrax.net>
To: dev@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
>> <an...@gmail.com> 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 <da...@gmail.com>
>>> To: dev@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 <an...@gmail.com>
>>> 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
>>>
>>>
>
Re: java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
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é <jb...@nanthrax.net>
To: dev@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
>> <an...@gmail.com> 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 <da...@gmail.com>
>>> To: dev@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 <an...@gmail.com>
>>> 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
>>>
>>>
>
Re: java 7 osgi core & compendium
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <an...@gmail.com> 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 <da...@gmail.com>
>> To: dev@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 <an...@gmail.com>
>> 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
>>
>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: java 7 osgi core & compendium
Posted by David Bosschaert <da...@gmail.com>.
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 <an...@gmail.com> 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 <da...@gmail.com>
> To: dev@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 <an...@gmail.com>
> 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
>
>
Re: java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
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 <da...@gmail.com>
To: dev@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 <an...@gmail.com> 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
>>
Re: java 7 osgi core & compendium
Posted by Christian Schneider <ch...@die-schneider.net>.
+1
That would be awesome.
Christian
On 10/08/2012 10:05 AM, David Bosschaert wrote:
> 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 <an...@gmail.com> 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
>>
Re: java 7 osgi core & compendium
Posted by David Bosschaert <da...@gmail.com>.
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 <an...@gmail.com> 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
>
Re: java 7 osgi core & compendium
Posted by Andreas Pieber <an...@gmail.com>.
Well Karaf already has it's own core distribution, sondern not much harm
adding one for the compendium too, independently, I've alway thoughts that
Felix might be the better location for it.
Kind regards,
Andreas
On Oct 5, 2012 9:03 PM, "Andrei Pozolotin" <an...@gmail.com>
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
>
>
java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
*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
Re: [DS] Feedback wanted on some ideas
Posted by Andrei Pozolotin <an...@gmail.com>.
great. I will study your sandbox.
-------- Original Message --------
Subject: Re: [DS] Feedback wanted on some ideas
From: Felix Meschberger <fm...@adobe.com>
To: dev@felix.apache.org <de...@felix.apache.org>
Date: Fri 05 Oct 2012 02:01:23 PM CDT
> Hi Andrei,
>
> Am 05.10.2012 um 20:54 schrieb Andrei Pozolotin:
>
>> Felix: great. can you please share link - what do you mean by "upcoming
>> spec "? Andrei.
> There is nothing public yet except the requirements available from OSGi Bug 147 [1] (where you commented already)
>
> The rest is work in progress in the OSGi Aliance which I cannot share yet. But the API will be based on what's in my sandbox at [2] (though there will be some changes).
>
> The "upcoming spec" is the spec enhancements we do to implement RFP-151 from Bug 147.
>
> Regards
> Felix
>
> [1] https://www.osgi.org/bugzilla/show_bug.cgi?id=147
> [2] http://svn.apache.org/repos/asf/felix/sandbox/fmeschbe/dsadmin/
>
>> -------- Original Message --------
>> Subject: Re: [DS] Feedback wanted on some ideas
>> From: Felix Meschberger <fm...@adobe.com>
>> To: dev@felix.apache.org <de...@felix.apache.org>
>> Date: Fri 05 Oct 2012 01:48:41 PM CDT
>>> Hi,
>>>
>>> Am 03.10.2012 um 19:39 schrieb Andrei Pozolotin:
>>>
>>>> great ideas; one more for your consideration
>>>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>>>> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
>>>> """
>>>>
>>>> public void *enableComponent*(java.lang.String name)
>>>>
>>>> Enables the specified component name. The specified component name
>>>> must be in the same bundle as this component.
>>>>
>>>> """
>>>>
>>>> instead, I suggest to permit traversal of bundle boundaries, so
>>>> enable/disable target can be anywhere.
>>> No. This would open security doors/holes.
>>>
>>> And as David indicates: The ScrService as well as the upcoming spec will allow for administrative enablement and disablement accross bundle boundaries (and the spec will include security considerations).
>>>
>>> Regards
>>> Felix
>>>
>>>> -------- Original Message --------
>>>> Subject: [DS] Feedback wanted on some ideas
>>>> From: David Jencks <da...@yahoo.com>
>>>> To: dev@felix.apache.org
>>>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>>>
>>>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>>>
>>>>> boolean tasksCompleted();
>>>>>
>>>>> void waitForTasksCompleted();
>>>>>
>>>>>
>>>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>>>
>>>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>>>
>>>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>>>
>>>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>>>
>>>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>>>
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>>
>
Re: [DS] Feedback wanted on some ideas
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 05.10.2012 um 23:38 schrieb Andrei Pozolotin:
> Felix:
>
> 1) will you accept comments on your sandbox?
Yes, I will accept comments.
>
> 2) if so, where should I post it?
You can post them here or create JIRA issues as you like.
Regards
Felix
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: [DS] Feedback wanted on some ideas
> From: Felix Meschberger <fm...@adobe.com>
> To: dev@felix.apache.org <de...@felix.apache.org>
> Date: Fri 05 Oct 2012 02:01:23 PM CDT
>> Hi Andrei,
>>
>> Am 05.10.2012 um 20:54 schrieb Andrei Pozolotin:
>>
>>> Felix: great. can you please share link - what do you mean by "upcoming
>>> spec "? Andrei.
>> There is nothing public yet except the requirements available from OSGi Bug 147 [1] (where you commented already)
>>
>> The rest is work in progress in the OSGi Aliance which I cannot share yet. But the API will be based on what's in my sandbox at [2] (though there will be some changes).
>>
>> The "upcoming spec" is the spec enhancements we do to implement RFP-151 from Bug 147.
>>
>> Regards
>> Felix
>>
>> [1] https://www.osgi.org/bugzilla/show_bug.cgi?id=147
>> [2] http://svn.apache.org/repos/asf/felix/sandbox/fmeschbe/dsadmin/
>>
>>> -------- Original Message --------
>>> Subject: Re: [DS] Feedback wanted on some ideas
>>> From: Felix Meschberger <fm...@adobe.com>
>>> To: dev@felix.apache.org <de...@felix.apache.org>
>>> Date: Fri 05 Oct 2012 01:48:41 PM CDT
>>>> Hi,
>>>>
>>>> Am 03.10.2012 um 19:39 schrieb Andrei Pozolotin:
>>>>
>>>>> great ideas; one more for your consideration
>>>>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>>>>> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
>>>>> """
>>>>>
>>>>> public void *enableComponent*(java.lang.String name)
>>>>>
>>>>> Enables the specified component name. The specified component name
>>>>> must be in the same bundle as this component.
>>>>>
>>>>> """
>>>>>
>>>>> instead, I suggest to permit traversal of bundle boundaries, so
>>>>> enable/disable target can be anywhere.
>>>> No. This would open security doors/holes.
>>>>
>>>> And as David indicates: The ScrService as well as the upcoming spec will allow for administrative enablement and disablement accross bundle boundaries (and the spec will include security considerations).
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>>> -------- Original Message --------
>>>>> Subject: [DS] Feedback wanted on some ideas
>>>>> From: David Jencks <da...@yahoo.com>
>>>>> To: dev@felix.apache.org
>>>>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>>>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>>>>
>>>>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>>>>
>>>>>> boolean tasksCompleted();
>>>>>>
>>>>>> void waitForTasksCompleted();
>>>>>>
>>>>>>
>>>>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>>>>
>>>>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>>>>
>>>>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>>>>
>>>>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>>>>
>>>>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>>>>
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>>
>>
>
Re: [DS] Feedback wanted on some ideas
Posted by Andrei Pozolotin <an...@gmail.com>.
Felix:
1) will you accept comments on your sandbox?
2) if so, where should I post it?
Andrei
-------- Original Message --------
Subject: Re: [DS] Feedback wanted on some ideas
From: Felix Meschberger <fm...@adobe.com>
To: dev@felix.apache.org <de...@felix.apache.org>
Date: Fri 05 Oct 2012 02:01:23 PM CDT
> Hi Andrei,
>
> Am 05.10.2012 um 20:54 schrieb Andrei Pozolotin:
>
>> Felix: great. can you please share link - what do you mean by "upcoming
>> spec "? Andrei.
> There is nothing public yet except the requirements available from OSGi Bug 147 [1] (where you commented already)
>
> The rest is work in progress in the OSGi Aliance which I cannot share yet. But the API will be based on what's in my sandbox at [2] (though there will be some changes).
>
> The "upcoming spec" is the spec enhancements we do to implement RFP-151 from Bug 147.
>
> Regards
> Felix
>
> [1] https://www.osgi.org/bugzilla/show_bug.cgi?id=147
> [2] http://svn.apache.org/repos/asf/felix/sandbox/fmeschbe/dsadmin/
>
>> -------- Original Message --------
>> Subject: Re: [DS] Feedback wanted on some ideas
>> From: Felix Meschberger <fm...@adobe.com>
>> To: dev@felix.apache.org <de...@felix.apache.org>
>> Date: Fri 05 Oct 2012 01:48:41 PM CDT
>>> Hi,
>>>
>>> Am 03.10.2012 um 19:39 schrieb Andrei Pozolotin:
>>>
>>>> great ideas; one more for your consideration
>>>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>>>> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
>>>> """
>>>>
>>>> public void *enableComponent*(java.lang.String name)
>>>>
>>>> Enables the specified component name. The specified component name
>>>> must be in the same bundle as this component.
>>>>
>>>> """
>>>>
>>>> instead, I suggest to permit traversal of bundle boundaries, so
>>>> enable/disable target can be anywhere.
>>> No. This would open security doors/holes.
>>>
>>> And as David indicates: The ScrService as well as the upcoming spec will allow for administrative enablement and disablement accross bundle boundaries (and the spec will include security considerations).
>>>
>>> Regards
>>> Felix
>>>
>>>> -------- Original Message --------
>>>> Subject: [DS] Feedback wanted on some ideas
>>>> From: David Jencks <da...@yahoo.com>
>>>> To: dev@felix.apache.org
>>>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>>>
>>>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>>>
>>>>> boolean tasksCompleted();
>>>>>
>>>>> void waitForTasksCompleted();
>>>>>
>>>>>
>>>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>>>
>>>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>>>
>>>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>>>
>>>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>>>
>>>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>>>
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>>
>
Re: [DS] Feedback wanted on some ideas
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Andrei,
Am 05.10.2012 um 20:54 schrieb Andrei Pozolotin:
> Felix: great. can you please share link - what do you mean by "upcoming
> spec "? Andrei.
There is nothing public yet except the requirements available from OSGi Bug 147 [1] (where you commented already)
The rest is work in progress in the OSGi Aliance which I cannot share yet. But the API will be based on what's in my sandbox at [2] (though there will be some changes).
The "upcoming spec" is the spec enhancements we do to implement RFP-151 from Bug 147.
Regards
Felix
[1] https://www.osgi.org/bugzilla/show_bug.cgi?id=147
[2] http://svn.apache.org/repos/asf/felix/sandbox/fmeschbe/dsadmin/
>
> -------- Original Message --------
> Subject: Re: [DS] Feedback wanted on some ideas
> From: Felix Meschberger <fm...@adobe.com>
> To: dev@felix.apache.org <de...@felix.apache.org>
> Date: Fri 05 Oct 2012 01:48:41 PM CDT
>> Hi,
>>
>> Am 03.10.2012 um 19:39 schrieb Andrei Pozolotin:
>>
>>> great ideas; one more for your consideration
>>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>>> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
>>> """
>>>
>>> public void *enableComponent*(java.lang.String name)
>>>
>>> Enables the specified component name. The specified component name
>>> must be in the same bundle as this component.
>>>
>>> """
>>>
>>> instead, I suggest to permit traversal of bundle boundaries, so
>>> enable/disable target can be anywhere.
>> No. This would open security doors/holes.
>>
>> And as David indicates: The ScrService as well as the upcoming spec will allow for administrative enablement and disablement accross bundle boundaries (and the spec will include security considerations).
>>
>> Regards
>> Felix
>>
>>> -------- Original Message --------
>>> Subject: [DS] Feedback wanted on some ideas
>>> From: David Jencks <da...@yahoo.com>
>>> To: dev@felix.apache.org
>>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>>
>>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>>
>>>> boolean tasksCompleted();
>>>>
>>>> void waitForTasksCompleted();
>>>>
>>>>
>>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>>
>>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>>
>>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>>
>>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>>
>>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>>
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>
>
Re: [DS] Feedback wanted on some ideas
Posted by Andrei Pozolotin <an...@gmail.com>.
Felix: great. can you please share link - what do you mean by "upcoming
spec "? Andrei.
-------- Original Message --------
Subject: Re: [DS] Feedback wanted on some ideas
From: Felix Meschberger <fm...@adobe.com>
To: dev@felix.apache.org <de...@felix.apache.org>
Date: Fri 05 Oct 2012 01:48:41 PM CDT
> Hi,
>
> Am 03.10.2012 um 19:39 schrieb Andrei Pozolotin:
>
>> great ideas; one more for your consideration
>> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
>> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
>> """
>>
>> public void *enableComponent*(java.lang.String name)
>>
>> Enables the specified component name. The specified component name
>> must be in the same bundle as this component.
>>
>> """
>>
>> instead, I suggest to permit traversal of bundle boundaries, so
>> enable/disable target can be anywhere.
> No. This would open security doors/holes.
>
> And as David indicates: The ScrService as well as the upcoming spec will allow for administrative enablement and disablement accross bundle boundaries (and the spec will include security considerations).
>
> Regards
> Felix
>
>> -------- Original Message --------
>> Subject: [DS] Feedback wanted on some ideas
>> From: David Jencks <da...@yahoo.com>
>> To: dev@felix.apache.org
>> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>>
>>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>>
>>> boolean tasksCompleted();
>>>
>>> void waitForTasksCompleted();
>>>
>>>
>>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>>
>>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>>
>>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>>
>>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>>
>>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>>
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>
java 7 osgi core & compendium
Posted by Andrei Pozolotin <an...@gmail.com>.
*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
Re: [DS] Feedback wanted on some ideas
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
Am 03.10.2012 um 19:39 schrieb Andrei Pozolotin:
> great ideas; one more for your consideration
> http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
> <http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
> """
>
> public void *enableComponent*(java.lang.String name)
>
> Enables the specified component name. The specified component name
> must be in the same bundle as this component.
>
> """
>
> instead, I suggest to permit traversal of bundle boundaries, so
> enable/disable target can be anywhere.
No. This would open security doors/holes.
And as David indicates: The ScrService as well as the upcoming spec will allow for administrative enablement and disablement accross bundle boundaries (and the spec will include security considerations).
Regards
Felix
>
> -------- Original Message --------
> Subject: [DS] Feedback wanted on some ideas
> From: David Jencks <da...@yahoo.com>
> To: dev@felix.apache.org
> Date: Wed 03 Oct 2012 12:28:49 PM CDT
>> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>>
>> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>>
>> boolean tasksCompleted();
>>
>> void waitForTasksCompleted();
>>
>>
>> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>>
>> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>>
>> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>>
>> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>>
>> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>>
>>
>> thanks
>> david jencks
>>
>>
>>
>
Re: [DS] Feedback wanted on some ideas
Posted by Andrei Pozolotin <an...@gmail.com>.
great ideas; one more for your consideration
http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
<http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
"""
public void *enableComponent*(java.lang.String name)
Enables the specified component name. The specified component name
must be in the same bundle as this component.
"""
instead, I suggest to permit traversal of bundle boundaries, so
enable/disable target can be anywhere.
-------- Original Message --------
Subject: [DS] Feedback wanted on some ideas
From: David Jencks <da...@yahoo.com>
To: dev@felix.apache.org
Date: Wed 03 Oct 2012 12:28:49 PM CDT
> I've had several ideas about DS enhancements, some of which I've implemented, and would like some feedback about how desirable they are before committing or proceeding with them.
>
> 1. (FELIX-3692) If you manually enable/disable components some of the work gets done asynchronously. I propose an api for finding out whether this work is done or waiting for it, something like
>
> boolean tasksCompleted();
>
> void waitForTasksCompleted();
>
>
> on ScrService. (suggestions for better names welcome :-) One use would be in our tests to replace the delay() call.
>
> 2. (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish a circular dependency between components. In some of these cases, the order in which the components are activated determines whether all the references are established. This is hard to understand from a users point of view :-). Sometimes it's possible to detect these situations and establish the reference asynchronously. The patch attached to the issue does this but needs a little more work to only try with services from DS components.
>
> For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.
>
> 3. (re-proposal) I'd like to propose moving the implementation to java 5 again with generics etc. The last time I suggested this there was a lot of pushback on the grounds that there are a lot of people using DS on limited platforms. However, none of these alleged :-) people is using trunk, because for several months the classes pulled from the concurrent library were wrong and trunk just didn't run on pre-java-5 vms. Are the compendium 4.3 spec classes we pull in even compatible with pre-java-5 vms?
>
> 4. (radical idea I haven't tried yet) I'm becoming increasingly convinced that the state objects in AbstractComponentManager mostly cause confusion and make the code more complicated and less reliable. The spec really only describes two states, enabled and disabled. The variations on enabled -- whether the component has all its dependencies satisfied, whether the service is registered, whether there are any implementation objects created -- all seem somewhat orthogonal and depend very much on the environment and don't seem to relate well to a single "dimension" of state. I'm considering trying to refactor the code that responds to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more "straight-through" with checks on the specific aspects of state that they need. Possibly we would want to put the "dynamic state" such as dependencies + instances in a single state object, but this is a different approach to the current state objects which have no internal state.
>
>
> thanks
> david jencks
>
>
>