Re: Release plan Oak 1.9.7

2018-08-09 Thread Davide Giannella 
between one thing and another we slipped to today.

As next Monday should be the date of an unstable release I'll wait
Monday to cut 1.9.7 sticking therefore to the schedule.

Davide

Re: Release plan Oak 1.9.7

2018-08-07 Thread Francesco Mari 
On Tue, 7 Aug 2018 at 20:14, Manfred Baedke 
wrote:

> Hi Francesco,
>
> are you sure you need the factoryPid?
>

You are right. There is no need to repeat the PID in the `factoryPid`
attribute in `@ObjectClassDefinition`. It's sufficient to set `factory` to
true in `@Designate`. In summary, the fix seems to be to drop the `factory`
attribute from `@Component`.


> I found this on migration of config factories from Felix to new OSGi
> annotations:
>
> Felix variation:
> https://techrevel.blog/2017/04/12/felix-configuration-factory/
> OSGi variation:
> https://techrevel.blog/2017/08/23/osgi-annotations-configuration-factory/
>
> On 8/7/2018 8:02 PM, Francesco Mari wrote:
>
> Hi Manfred,
>
> Thanks for you suggestion. I'm currently experimenting with dropping the
> `factory` attribute from `@Component` and setting the `factoryPid`
> attribute in `@ObjectClassDefinition`. This seems to produce the wanted
> result in both the component and metatype descriptors. I will run more
> tests tomorrow.
>
> On Tue, 7 Aug 2018 at 19:56, Manfred Baedke 
> wrote:
>
>> Hi Francesco,
>>
>> I think that you don't want to make this a factory component but instead
>> you want to use a factory configuration (the difference being a
>> component lifecycle control thing, if I got that right - ask a real OSGi
>> expert :)). Just try dropping the factory attribute from the Component
>> annotation and you should be fine.
>>
>> On 8/7/2018 6:32 PM, Francesco Mari wrote:
>> > The weird situation I'm looking into is that before my commit (e.g. at
>> > 01c07cfec2), the component descriptor for SegmentNodeStoreFactory,
>> > generated with the old annotations, contained a declaration like the
>> > following (whitespaces included for clarity):
>> >
>> > > >  xmlns:scr="http://www.osgi.org/xmlns/scr/v1.2.0;
>> >  name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
>> >  configuration-policy="require"
>> >  activate="activate"
>> >  deactivate="deactivate">
>> >
>> > After my commit, in trunk, using the new annotations, the component
>> > descriptor contains the following:
>> >
>> > > >  xmlns:scr="http://www.osgi.org/xmlns/scr/v1.3.0;
>> >
>> name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
>> >  configuration-policy="require"
>> >
>> factory="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
>> >  activate="activate"
>> >  deactivate="deactivate">
>> >
>> > According to the declarative services specification [1], "a factory
>> > component is used if the 'factory' attribute of the 'component' element
>> is
>> > set to a factory identifier". Isn't then my commit actually fixing the
>> > component descriptor?
>> >
>> > [1]:
>> >
>> https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent
>> >
>> >
>> > On Tue, 7 Aug 2018 at 16:00, Francesco Mari 
>> > wrote:
>> >
>> >> The issue is weird. The activate method of SegmentNodeStoreFactory is
>> not
>> >> even called. As far as I know, all the other tests in oak-pojosr are
>> >> working correctly. I will look into it.
>> >>
>> >> On Tue, 7 Aug 2018 at 15:19, Marcel Reutegger
>>  
>> >> wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>> On 07.08.18 14:57, Davide Giannella wrote:
>>  Hello team, there are no blockers for the issues as of now. If none
>> will
>>  come I'll proceed with the cut tomorrow Wednesday 8th August.
>> >>> I'd like to highlight OAK-6770. I just re-opened that issue, which has
>> >>> changes that would go into the release.
>> >>>
>> >>> Regards
>> >>>Marcel
>> >>>
>>
>>
>

Re: Release plan Oak 1.9.7

2018-08-07 Thread Manfred Baedke 

Hi Francesco,

are you sure you need the factoryPid?
I found this on migration of config factories from Felix to new OSGi 
annotations:


Felix variation: 
https://techrevel.blog/2017/04/12/felix-configuration-factory/
OSGi 
variation:https://techrevel.blog/2017/08/23/osgi-annotations-configuration-factory/


On 8/7/2018 8:02 PM, Francesco Mari wrote:

Hi Manfred,

Thanks for you suggestion. I'm currently experimenting with dropping 
the `factory` attribute from `@Component` and setting the `factoryPid` 
attribute in `@ObjectClassDefinition`. This seems to produce the 
wanted result in both the component and metatype descriptors. I will 
run more tests tomorrow.


On Tue, 7 Aug 2018 at 19:56, Manfred Baedke > wrote:


Hi Francesco,

I think that you don't want to make this a factory component but
instead
you want to use a factory configuration (the difference being a
component lifecycle control thing, if I got that right - ask a
real OSGi
expert :)). Just try dropping the factory attribute from the
Component
annotation and you should be fine.

On 8/7/2018 6:32 PM, Francesco Mari wrote:
> The weird situation I'm looking into is that before my commit
(e.g. at
> 01c07cfec2), the component descriptor for SegmentNodeStoreFactory,
> generated with the old annotations, contained a declaration like the
> following (whitespaces included for clarity):
>
>       xmlns:scr="http://www.osgi.org/xmlns/scr/v1.2.0;
> name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
>      configuration-policy="require"
>      activate="activate"
>      deactivate="deactivate">
>
> After my commit, in trunk, using the new annotations, the component
> descriptor contains the following:
>
>           xmlns:scr="http://www.osgi.org/xmlns/scr/v1.3.0;
> name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
>          configuration-policy="require"
> factory="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
>          activate="activate"
>          deactivate="deactivate">
>
> According to the declarative services specification [1], "a factory
> component is used if the 'factory' attribute of the 'component'
element is
> set to a factory identifier". Isn't then my commit actually
fixing the
> component descriptor?
>
> [1]:
>

https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent
>
>
> On Tue, 7 Aug 2018 at 16:00, Francesco Mari
mailto:mari.france...@gmail.com>>
> wrote:
>
>> The issue is weird. The activate method of
SegmentNodeStoreFactory is not
>> even called. As far as I know, all the other tests in
oak-pojosr are
>> working correctly. I will look into it.
>>
>> On Tue, 7 Aug 2018 at 15:19, Marcel Reutegger

>> wrote:
>>
>>> Hi,
>>>
>>> On 07.08.18 14:57, Davide Giannella wrote:
 Hello team, there are no blockers for the issues as of now.
If none will
 come I'll proceed with the cut tomorrow Wednesday 8th August.
>>> I'd like to highlight OAK-6770. I just re-opened that issue,
which has
>>> changes that would go into the release.
>>>
>>> Regards
>>>    Marcel
>>>

Re: Release plan Oak 1.9.7

2018-08-07 Thread Francesco Mari 
Hi Manfred,

Thanks for you suggestion. I'm currently experimenting with dropping the
`factory` attribute from `@Component` and setting the `factoryPid`
attribute in `@ObjectClassDefinition`. This seems to produce the wanted
result in both the component and metatype descriptors. I will run more
tests tomorrow.

On Tue, 7 Aug 2018 at 19:56, Manfred Baedke 
wrote:

> Hi Francesco,
>
> I think that you don't want to make this a factory component but instead
> you want to use a factory configuration (the difference being a
> component lifecycle control thing, if I got that right - ask a real OSGi
> expert :)). Just try dropping the factory attribute from the Component
> annotation and you should be fine.
>
> On 8/7/2018 6:32 PM, Francesco Mari wrote:
> > The weird situation I'm looking into is that before my commit (e.g. at
> > 01c07cfec2), the component descriptor for SegmentNodeStoreFactory,
> > generated with the old annotations, contained a declaration like the
> > following (whitespaces included for clarity):
> >
> >  >  xmlns:scr="http://www.osgi.org/xmlns/scr/v1.2.0;
> >  name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
> >  configuration-policy="require"
> >  activate="activate"
> >  deactivate="deactivate">
> >
> > After my commit, in trunk, using the new annotations, the component
> > descriptor contains the following:
> >
> >  >  xmlns:scr="http://www.osgi.org/xmlns/scr/v1.3.0;
> >  name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
> >  configuration-policy="require"
> >
> factory="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
> >  activate="activate"
> >  deactivate="deactivate">
> >
> > According to the declarative services specification [1], "a factory
> > component is used if the 'factory' attribute of the 'component' element
> is
> > set to a factory identifier". Isn't then my commit actually fixing the
> > component descriptor?
> >
> > [1]:
> >
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent
> >
> >
> > On Tue, 7 Aug 2018 at 16:00, Francesco Mari 
> > wrote:
> >
> >> The issue is weird. The activate method of SegmentNodeStoreFactory is
> not
> >> even called. As far as I know, all the other tests in oak-pojosr are
> >> working correctly. I will look into it.
> >>
> >> On Tue, 7 Aug 2018 at 15:19, Marcel Reutegger
> 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> On 07.08.18 14:57, Davide Giannella wrote:
>  Hello team, there are no blockers for the issues as of now. If none
> will
>  come I'll proceed with the cut tomorrow Wednesday 8th August.
> >>> I'd like to highlight OAK-6770. I just re-opened that issue, which has
> >>> changes that would go into the release.
> >>>
> >>> Regards
> >>>Marcel
> >>>
>
>

Re: Release plan Oak 1.9.7

2018-08-07 Thread Manfred Baedke 

Hi Francesco,

I think that you don't want to make this a factory component but instead 
you want to use a factory configuration (the difference being a 
component lifecycle control thing, if I got that right - ask a real OSGi 
expert :)). Just try dropping the factory attribute from the Component 
annotation and you should be fine.


On 8/7/2018 6:32 PM, Francesco Mari wrote:

The weird situation I'm looking into is that before my commit (e.g. at
01c07cfec2), the component descriptor for SegmentNodeStoreFactory,
generated with the old annotations, contained a declaration like the
following (whitespaces included for clarity):

http://www.osgi.org/xmlns/scr/v1.2.0;
 name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
 configuration-policy="require"
 activate="activate"
 deactivate="deactivate">

After my commit, in trunk, using the new annotations, the component
descriptor contains the following:

http://www.osgi.org/xmlns/scr/v1.3.0;
 name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
 configuration-policy="require"
 factory="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
 activate="activate"
 deactivate="deactivate">

According to the declarative services specification [1], "a factory
component is used if the 'factory' attribute of the 'component' element is
set to a factory identifier". Isn't then my commit actually fixing the
component descriptor?

[1]:
https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent


On Tue, 7 Aug 2018 at 16:00, Francesco Mari 
wrote:


The issue is weird. The activate method of SegmentNodeStoreFactory is not
even called. As far as I know, all the other tests in oak-pojosr are
working correctly. I will look into it.

On Tue, 7 Aug 2018 at 15:19, Marcel Reutegger 
wrote:


Hi,

On 07.08.18 14:57, Davide Giannella wrote:

Hello team, there are no blockers for the issues as of now. If none will
come I'll proceed with the cut tomorrow Wednesday 8th August.

I'd like to highlight OAK-6770. I just re-opened that issue, which has
changes that would go into the release.

Regards
   Marcel

Re: Release plan Oak 1.9.7

2018-08-07 Thread Francesco Mari 
The weird situation I'm looking into is that before my commit (e.g. at
01c07cfec2), the component descriptor for SegmentNodeStoreFactory,
generated with the old annotations, contained a declaration like the
following (whitespaces included for clarity):

http://www.osgi.org/xmlns/scr/v1.2.0;
name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
configuration-policy="require"
activate="activate"
deactivate="deactivate">

After my commit, in trunk, using the new annotations, the component
descriptor contains the following:

http://www.osgi.org/xmlns/scr/v1.3.0;
name="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
configuration-policy="require"
factory="org.apache.jackrabbit.oak.segment.SegmentNodeStoreFactory"
activate="activate"
deactivate="deactivate">

According to the declarative services specification [1], "a factory
component is used if the 'factory' attribute of the 'component' element is
set to a factory identifier". Isn't then my commit actually fixing the
component descriptor?

[1]:
https://osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-factorycomponent


On Tue, 7 Aug 2018 at 16:00, Francesco Mari 
wrote:

> The issue is weird. The activate method of SegmentNodeStoreFactory is not
> even called. As far as I know, all the other tests in oak-pojosr are
> working correctly. I will look into it.
>
> On Tue, 7 Aug 2018 at 15:19, Marcel Reutegger 
> wrote:
>
>> Hi,
>>
>> On 07.08.18 14:57, Davide Giannella wrote:
>> > Hello team, there are no blockers for the issues as of now. If none will
>> > come I'll proceed with the cut tomorrow Wednesday 8th August.
>>
>> I'd like to highlight OAK-6770. I just re-opened that issue, which has
>> changes that would go into the release.
>>
>> Regards
>>   Marcel
>>
>

Re: Release plan Oak 1.9.7

2018-08-07 Thread Francesco Mari 
The issue is weird. The activate method of SegmentNodeStoreFactory is not
even called. As far as I know, all the other tests in oak-pojosr are
working correctly. I will look into it.

On Tue, 7 Aug 2018 at 15:19, Marcel Reutegger 
wrote:

> Hi,
>
> On 07.08.18 14:57, Davide Giannella wrote:
> > Hello team, there are no blockers for the issues as of now. If none will
> > come I'll proceed with the cut tomorrow Wednesday 8th August.
>
> I'd like to highlight OAK-6770. I just re-opened that issue, which has
> changes that would go into the release.
>
> Regards
>   Marcel
>

Re: Release plan Oak 1.9.7

2018-08-07 Thread Marcel Reutegger 

Hi,

On 07.08.18 14:57, Davide Giannella wrote:

Hello team, there are no blockers for the issues as of now. If none will
come I'll proceed with the cut tomorrow Wednesday 8th August.


I'd like to highlight OAK-6770. I just re-opened that issue, which has 
changes that would go into the release.


Regards
 Marcel

Re: Release plan Oak 1.9.7

2018-08-07 Thread Davide Giannella 
On 27/07/2018 07:46, Amit Jain wrote:
> Hi,
>
> My plan is to release Oak 1.9.7 early next week. I'll wait for resolution
> of OAK-7656 and OAK-7569.
>

Hello team, there are no blockers for the issues as of now. If none will
come I'll proceed with the cut tomorrow Wednesday 8th August.

Objections please reply.

Davide