Re: [VOTE] Release Apache Felix WebConsole 4.2.14

[Pierre De Rop]

Indeed ! wow ! we only have the problem when building with java8; and not
with java7; that is odd.

+1

However, according to the apache release process, I think that binary
artifacts are only produced as convenience for users , and source artifacts
are more important than binaries; So, I think that when sending the
announce your should then mention the fact that the source release must be
only built using java7 and not java8.

cheers
/Pierre






On Fri, Oct 2, 2015 at 5:42 PM, Carsten Ziegeler 
wrote:

> Am 02.10.15 um 17:38 schrieb Carsten Ziegeler:
>
> >
> > Interestingly, it seems to have to do with your build environment,
> > whether the import ends up in the manifest or not. If I build on my
> > machine, java 7, it's not there.
> >
> And with java 8 it is there, so it really depends on the java version
> you build with :(
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

[Carsten Ziegeler]

I assume this is due to a very old parent pom - or a misconfiguration in
that parent pom. Should really be easy to fix.

Carsten

Am 02.10.15 um 19:14 schrieb David Jencks:
> I’d vote for just moving to a gradle/bndtools build….
> 
> A little experimentation suggests that the maven-bundle-plugin 2.4.3 used in 
> command can’t produce source jars whereas the 1.4.3 version used in shell 
> can.  the 2.4.3 version produces this output:
> 
> [INFO] --- maven-source-plugin:2.0.4:jar (default-cli) @ 
> org.apache.felix.gogo.command ---
> [WARNING] NOT adding sources to artifacts with classifier as Maven only 
> supports one classifier per artifact. Current artifact 
> [org.apache.felix:org.apache.felix.gogo.command:bundle:0.16.0] has a [] 
> classifier.
> 
> instead of making the requested jar.
> 
> david jencks
> 
>> On Oct 2, 2015, at 12:42 PM, Benson Margulies  wrote:
>>
>> I could take a look at this for the next iteration.
>>
>>
>> On Fri, Oct 2, 2015 at 12:41 PM, David Jencks
>>  wrote:
>>> Hi David,
>>>
>>> Well, I was sort of hoping you’d figure out a way to release the sources 
>>> bundle too :-).  However I can create my own for my needs.  I’ve now tested 
>>> the fixes I added and they seem to work, so, at long last,
>>>
>>> +1
>>>
>>> thanks
>>> david jencks
>>>
>>>
 On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:

 Hi David,

 I didn't change the build process for these artifacts, so I guess they
 were released like this before. In any case, the important artifacts
 are there. We can change the produced artifacts for a future release,
 but I don't think this is important enough to cancel this one.

 BTW I can't count your email as a +1 or -1, so please indicate how you
 actually vote here.

 Thanks,

 David

 On 1 October 2015 at 18:19, David Jencks  
 wrote:
> sigs look good, I can build the project tar.gzs.
>
> The selection of artifacts looks a bit bizarre to me.  I don’t see a 
> sources bundle for org.apache.felix.gogo.command-0.16.0 and I can’t 
> imagine what the bin artifacts are for.  Is this all intentional?
> I’d really prefer there be a 
> org.apache.felix.gogo.command-0.16.0-sources.jar
>
> thanks for undertaking this release :-)
>
> david jencks
>
>> On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:
>>
>> Hi all,
>>
>> I'm calling a vote on the following bundles:
>>
>> Felix Gogo Shell 0.12.0
>> ** Improvement
>>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>>  * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
>> a bundle fragment
>>  * FELIX-3341 Simple csh-like Command History
>>  * FELIX-3340 Allow the prompt to be a Function
>>
>> ** Bug
>>  * FELIX-4425 Short command in Gogo Shell not working with Java 8
>>  * FELIX-3706 gogo shell startup failure in busy system
>>  * FELIX-3703 Race condition in gogo runtime activator
>>
>> Felix Gogo Command 0.16.0
>> ** Improvement
>>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>>  * FELIX-5009 Relative URIs would be nice for install and update
>>  * FELIX-5008 gogo usage messages could be less confusing
>>  * FELIX-3499 felix:cd command works only with relative paths
>>
>> ** Bug
>>  * FELIX-4969 cd refuses to leave initial directory
>>
>> Note that not changes have been made to the Felix Gogo Runtime bundle
>> since the last release.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1096
>>
>> You can use this UNIX script to download the release and verify the 
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> This vote will remain open for at least 72 hours.
>>
>> Best regards,
>>
>> David Bosschaert
>
>>>
> 
> 


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

[David Jencks]

I’d vote for just moving to a gradle/bndtools build….

A little experimentation suggests that the maven-bundle-plugin 2.4.3 used in 
command can’t produce source jars whereas the 1.4.3 version used in shell can.  
the 2.4.3 version produces this output:

[INFO] --- maven-source-plugin:2.0.4:jar (default-cli) @ 
org.apache.felix.gogo.command ---
[WARNING] NOT adding sources to artifacts with classifier as Maven only 
supports one classifier per artifact. Current artifact 
[org.apache.felix:org.apache.felix.gogo.command:bundle:0.16.0] has a [] 
classifier.

instead of making the requested jar.

david jencks

> On Oct 2, 2015, at 12:42 PM, Benson Margulies  wrote:
> 
> I could take a look at this for the next iteration.
> 
> 
> On Fri, Oct 2, 2015 at 12:41 PM, David Jencks
>  wrote:
>> Hi David,
>> 
>> Well, I was sort of hoping you’d figure out a way to release the sources 
>> bundle too :-).  However I can create my own for my needs.  I’ve now tested 
>> the fixes I added and they seem to work, so, at long last,
>> 
>> +1
>> 
>> thanks
>> david jencks
>> 
>> 
>>> On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:
>>> 
>>> Hi David,
>>> 
>>> I didn't change the build process for these artifacts, so I guess they
>>> were released like this before. In any case, the important artifacts
>>> are there. We can change the produced artifacts for a future release,
>>> but I don't think this is important enough to cancel this one.
>>> 
>>> BTW I can't count your email as a +1 or -1, so please indicate how you
>>> actually vote here.
>>> 
>>> Thanks,
>>> 
>>> David
>>> 
>>> On 1 October 2015 at 18:19, David Jencks  
>>> wrote:
 sigs look good, I can build the project tar.gzs.
 
 The selection of artifacts looks a bit bizarre to me.  I don’t see a 
 sources bundle for org.apache.felix.gogo.command-0.16.0 and I can’t 
 imagine what the bin artifacts are for.  Is this all intentional?
 I’d really prefer there be a 
 org.apache.felix.gogo.command-0.16.0-sources.jar
 
 thanks for undertaking this release :-)
 
 david jencks
 
> On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:
> 
> Hi all,
> 
> I'm calling a vote on the following bundles:
> 
> Felix Gogo Shell 0.12.0
> ** Improvement
>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>  * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
> a bundle fragment
>  * FELIX-3341 Simple csh-like Command History
>  * FELIX-3340 Allow the prompt to be a Function
> 
> ** Bug
>  * FELIX-4425 Short command in Gogo Shell not working with Java 8
>  * FELIX-3706 gogo shell startup failure in busy system
>  * FELIX-3703 Race condition in gogo runtime activator
> 
> Felix Gogo Command 0.16.0
> ** Improvement
>  * FELIX-5021 [GOGO] Use system bundle to find bundles
>  * FELIX-5009 Relative URIs would be nice for install and update
>  * FELIX-5008 gogo usage messages could be less confusing
>  * FELIX-3499 felix:cd command works only with relative paths
> 
> ** Bug
>  * FELIX-4969 cd refuses to leave initial directory
> 
> Note that not changes have been made to the Felix Gogo Runtime bundle
> since the last release.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1096
> 
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> 
> Usage:
> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will remain open for at least 72 hours.
> 
> Best regards,
> 
> David Bosschaert
 
>> 

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

[David Jencks]

Hi David,

Well, I was sort of hoping you’d figure out a way to release the sources bundle 
too :-).  However I can create my own for my needs.  I’ve now tested the fixes 
I added and they seem to work, so, at long last,

+1

thanks
david jencks


> On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:
> 
> Hi David,
> 
> I didn't change the build process for these artifacts, so I guess they
> were released like this before. In any case, the important artifacts
> are there. We can change the produced artifacts for a future release,
> but I don't think this is important enough to cancel this one.
> 
> BTW I can't count your email as a +1 or -1, so please indicate how you
> actually vote here.
> 
> Thanks,
> 
> David
> 
> On 1 October 2015 at 18:19, David Jencks  
> wrote:
>> sigs look good, I can build the project tar.gzs.
>> 
>> The selection of artifacts looks a bit bizarre to me.  I don’t see a sources 
>> bundle for org.apache.felix.gogo.command-0.16.0 and I can’t imagine what the 
>> bin artifacts are for.  Is this all intentional?
>> I’d really prefer there be a org.apache.felix.gogo.command-0.16.0-sources.jar
>> 
>> thanks for undertaking this release :-)
>> 
>> david jencks
>> 
>>> On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:
>>> 
>>> Hi all,
>>> 
>>> I'm calling a vote on the following bundles:
>>> 
>>> Felix Gogo Shell 0.12.0
>>> ** Improvement
>>>   * FELIX-5021 [GOGO] Use system bundle to find bundles
>>>   * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
>>> a bundle fragment
>>>   * FELIX-3341 Simple csh-like Command History
>>>   * FELIX-3340 Allow the prompt to be a Function
>>> 
>>> ** Bug
>>>   * FELIX-4425 Short command in Gogo Shell not working with Java 8
>>>   * FELIX-3706 gogo shell startup failure in busy system
>>>   * FELIX-3703 Race condition in gogo runtime activator
>>> 
>>> Felix Gogo Command 0.16.0
>>> ** Improvement
>>>   * FELIX-5021 [GOGO] Use system bundle to find bundles
>>>   * FELIX-5009 Relative URIs would be nice for install and update
>>>   * FELIX-5008 gogo usage messages could be less confusing
>>>   * FELIX-3499 felix:cd command works only with relative paths
>>> 
>>> ** Bug
>>>   * FELIX-4969 cd refuses to leave initial directory
>>> 
>>> Note that not changes have been made to the Felix Gogo Runtime bundle
>>> since the last release.
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachefelix-1096
>>> 
>>> You can use this UNIX script to download the release and verify the 
>>> signatures:
>>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>> 
>>> Usage:
>>> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>>> This vote will remain open for at least 72 hours.
>>> 
>>> Best regards,
>>> 
>>> David Bosschaert
>> 

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

[Benson Margulies]

I could take a look at this for the next iteration.


On Fri, Oct 2, 2015 at 12:41 PM, David Jencks
 wrote:
> Hi David,
>
> Well, I was sort of hoping you’d figure out a way to release the sources 
> bundle too :-).  However I can create my own for my needs.  I’ve now tested 
> the fixes I added and they seem to work, so, at long last,
>
> +1
>
> thanks
> david jencks
>
>
>> On Oct 1, 2015, at 6:25 PM, dav...@apache.org wrote:
>>
>> Hi David,
>>
>> I didn't change the build process for these artifacts, so I guess they
>> were released like this before. In any case, the important artifacts
>> are there. We can change the produced artifacts for a future release,
>> but I don't think this is important enough to cancel this one.
>>
>> BTW I can't count your email as a +1 or -1, so please indicate how you
>> actually vote here.
>>
>> Thanks,
>>
>> David
>>
>> On 1 October 2015 at 18:19, David Jencks  
>> wrote:
>>> sigs look good, I can build the project tar.gzs.
>>>
>>> The selection of artifacts looks a bit bizarre to me.  I don’t see a 
>>> sources bundle for org.apache.felix.gogo.command-0.16.0 and I can’t imagine 
>>> what the bin artifacts are for.  Is this all intentional?
>>> I’d really prefer there be a 
>>> org.apache.felix.gogo.command-0.16.0-sources.jar
>>>
>>> thanks for undertaking this release :-)
>>>
>>> david jencks
>>>
 On Oct 1, 2015, at 4:42 AM, dav...@apache.org wrote:

 Hi all,

 I'm calling a vote on the following bundles:

 Felix Gogo Shell 0.12.0
 ** Improvement
   * FELIX-5021 [GOGO] Use system bundle to find bundles
   * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
 a bundle fragment
   * FELIX-3341 Simple csh-like Command History
   * FELIX-3340 Allow the prompt to be a Function

 ** Bug
   * FELIX-4425 Short command in Gogo Shell not working with Java 8
   * FELIX-3706 gogo shell startup failure in busy system
   * FELIX-3703 Race condition in gogo runtime activator

 Felix Gogo Command 0.16.0
 ** Improvement
   * FELIX-5021 [GOGO] Use system bundle to find bundles
   * FELIX-5009 Relative URIs would be nice for install and update
   * FELIX-5008 gogo usage messages could be less confusing
   * FELIX-3499 felix:cd command works only with relative paths

 ** Bug
   * FELIX-4969 cd refuses to leave initial directory

 Note that not changes have been made to the Felix Gogo Runtime bundle
 since the last release.

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachefelix-1096

 You can use this UNIX script to download the release and verify the 
 signatures:
 http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

 Usage:
 sh check_staged_release.sh 1096 /tmp/felix-gogo-check

 Please vote to approve this release:

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

 This vote will remain open for at least 72 hours.

 Best regards,

 David Bosschaert
>>>
>

[jira] [Commented] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

[Thomas Watson (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941336#comment-14941336
 ] 

Thomas Watson commented on FELIX-5061:
--

I did add a new testcase to Equinox for this case.  You can find it in the 
twatson/newResolver branch as I described in FELIX-4987

> Optional resource fragment with requirements that cause class space 
> consistency issues with the host export cause unexpected ResolutionExceptions
> -
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Thomas Watson
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint 
> conflict with one of the hosts exported packages then the resolver will end 
> up throwing a ResolutionExceptoin even when the fragment and host are 
> considered to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

[Thomas Watson (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14941302#comment-14941302
 ] 

Thomas Watson edited comment on FELIX-5061 at 10/2/15 4:08 PM:
---

Here is a possible fix.  The issue is the loop used to call  
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host 
resources.  I like that change and do not suggest that we change that.

Before it used to loop over all the 'seed' resources and check their 
consistency.  This included any fragments that are mandatory or optional 
resources according to the ResolveContext.  When checking the consistency of 
the fragment the impl would first find its hosts and do the check on the host, 
but the original fragment resource was kept for the faulty resource and could 
therefore be optionally removed from the resolution and we would retry 
resolution without the fragment.

Now we have lost the context of the fragment seeds and only have their hosts 
and that causes the issues.  At first I was thinking we needed to somehow bring 
the context back for the fragment during the consistency check, but that proved 
to be overcomplicated.

Instead I decided to fix an issue with the UseConstraintError so that we report 
back the Requirement that is to blame for the conflict with the host export.  
That way the bit of code in ResolverImpl.checkConsistency that finds the faulty 
resource will correctly detect faultyReq is a WrappedRequirement from a 
fragment resource.

This also fixes an existing issue in the prior implementation that would end up 
throwing out the host as well even though it could have resolved the host once 
the fragment was removed from resolution.


was (Author: tjwatson):
Here is a possible fix.  The issue is the loop used to call  
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host 
resources.  I like that change and do not suggest that we change that.

Before it use to loop over all the 'seed' resources and check their 
consistency.  This included any fragments that would mandatory or optional 
resources.  When checking the consistency of the fragment the impl would first 
find its hosts and do the check on the host, but the original fragment resource 
was kept for the faulty resource and could therefore be optionally removed from 
the resolution and we would retry.

Now we have lost the context of the fragment seeds and only have their hosts 
and that causes the issues.  At first I was thinking we needed to somehow bring 
the context back for the fragment during the consistency check, but that proved 
to be overcomplicated.

Instead I decided to fix an issue with the UseConstraintError so that we report 
back the Requirement that is to blame for the conflict with the host export.  
That way the bit of code ResolverImpl.checkConsistency the finds the faulty 
will correctly detect faultyReq is a WrappedRequirement from a fragment bundle.

> Optional resource fragment with requirements that cause class space 
> consistency issues with the host export cause unexpected ResolutionExceptions
> -
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Thomas Watson
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint 
> conflict with one of the hosts exported packages then the resolver will end 
> up throwing a ResolutionExceptoin even when the fragment and host are 
> considered to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

[Thomas Watson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Watson updated FELIX-5061:
-
Attachment: FELIX-5061.patch

Here is a possible fix.  The issue is the loop used to call  
ResolverImpl.checkPackageSpaceConsistency changed to only loop over host 
resources.  I like that change and do not suggest that we change that.

Before it use to loop over all the 'seed' resources and check their 
consistency.  This included any fragments that would mandatory or optional 
resources.  When checking the consistency of the fragment the impl would first 
find its hosts and do the check on the host, but the original fragment resource 
was kept for the faulty resource and could therefore be optionally removed from 
the resolution and we would retry.

Now we have lost the context of the fragment seeds and only have their hosts 
and that causes the issues.  At first I was thinking we needed to somehow bring 
the context back for the fragment during the consistency check, but that proved 
to be overcomplicated.

Instead I decided to fix an issue with the UseConstraintError so that we report 
back the Requirement that is to blame for the conflict with the host export.  
That way the bit of code ResolverImpl.checkConsistency the finds the faulty 
will correctly detect faultyReq is a WrappedRequirement from a fragment bundle.

> Optional resource fragment with requirements that cause class space 
> consistency issues with the host export cause unexpected ResolutionExceptions
> -
>
> Key: FELIX-5061
> URL: https://issues.apache.org/jira/browse/FELIX-5061
> Project: Felix
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: resolver-1.6.0
>Reporter: Thomas Watson
> Attachments: FELIX-5061.patch
>
>
> Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
> latest out of trunk so it could be something after 1.6.0.
> If a fragment contains a requirement that ultimately causes a uses constraint 
> conflict with one of the hosts exported packages then the resolver will end 
> up throwing a ResolutionExceptoin even when the fragment and host are 
> considered to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

[Carsten Ziegeler]

Am 02.10.15 um 17:38 schrieb Carsten Ziegeler:

> 
> Interestingly, it seems to have to do with your build environment,
> whether the import ends up in the manifest or not. If I build on my
> machine, java 7, it's not there.
> 
And with java 8 it is there, so it really depends on the java version
you build with :(

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

[Carsten Ziegeler]

Am 02.10.15 um 17:27 schrieb Pierre De Rop:
> Hello Carsten,
> 
> There is something that I don't understand regarding the FELIX-5060
>  issue:
> 
> Indeed, the org.osgi.service.component package is not imported anymore from
> the binary artifact (in
> /tmp/felix-staging/1097/org/apache/felix/org.apache.felix.webconsole/4.2.14/org.apache.felix.webconsole-4.2.14.jar).
> So, it's Ok for the binary artifact.
> 
> However, after rebuilding the binary from the sources, the package is again
> imported, and it is because the BundlesServlet class is importing the
> org.osgi.service.component.ComponentConstants).
> 
> So, shouldn't the BundlesServlet be modified in order to not depend anymore
> on the ComponentConstants from the DS API ?
> 
Thanks Pierre for finding this. Yes, we should remove it - I'll take
care of it.
I don't think we have to redo the 4.2.14 as the binary is fine. WDYT?

Interestingly, it seems to have to do with your build environment,
whether the import ends up in the manifest or not. If I build on my
machine, java 7, it's not there.

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

[Pierre De Rop]

Hello Carsten,

There is something that I don't understand regarding the FELIX-5060
 issue:

Indeed, the org.osgi.service.component package is not imported anymore from
the binary artifact (in
/tmp/felix-staging/1097/org/apache/felix/org.apache.felix.webconsole/4.2.14/org.apache.felix.webconsole-4.2.14.jar).
So, it's Ok for the binary artifact.

However, after rebuilding the binary from the sources, the package is again
imported, and it is because the BundlesServlet class is importing the
org.osgi.service.component.ComponentConstants).

So, shouldn't the BundlesServlet be modified in order to not depend anymore
on the ComponentConstants from the DS API ?

thanks;


BR
/pierre



On Fri, Oct 2, 2015 at 4:37 PM, David Bosschaert  wrote:

> +1
>
> David
>
> On 2 October 2015 at 16:28, Carsten Ziegeler  wrote:
> > I would like to call a vote for a new web console release:
> > We fixed two issues:
> > https://issues.apache.org/jira/browse/FELIX/fixforversion/12333546
> >
> > Staging repositories:
> > https://repository.apache.org/content/repositories/orgapachefelix-1097/
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 10697 /tmp/felix-staging
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
>

[jira] [Created] (FELIX-5061) Optional resource fragment with requirements that cause class space consistency issues with the host export cause unexpected ResolutionExceptions

[Thomas Watson (JIRA)]

Thomas Watson created FELIX-5061:


 Summary: Optional resource fragment with requirements that cause 
class space consistency issues with the host export cause unexpected 
ResolutionExceptions
 Key: FELIX-5061
 URL: https://issues.apache.org/jira/browse/FELIX-5061
 Project: Felix
  Issue Type: Bug
  Components: Resolver
Affects Versions: resolver-1.6.0
Reporter: Thomas Watson


Not sure if this is actually a bug in version 1.6.0.  I am testing with the 
latest out of trunk so it could be something after 1.6.0.

If a fragment contains a requirement that ultimately causes a uses constraint 
conflict with one of the hosts exported packages then the resolver will end up 
throwing a ResolutionExceptoin even when the fragment and host are considered 
to be optional resources by the ResolverContext.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

[David Bosschaert]

+1

David

On 2 October 2015 at 16:28, Carsten Ziegeler  wrote:
> I would like to call a vote for a new web console release:
> We fixed two issues:
> https://issues.apache.org/jira/browse/FELIX/fixforversion/12333546
>
> Staging repositories:
> https://repository.apache.org/content/repositories/orgapachefelix-1097/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 10697 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Felix WebConsole 4.2.14

[Carsten Ziegeler]

+1


-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[VOTE] Release Apache Felix WebConsole 4.2.14

[Carsten Ziegeler]

I would like to call a vote for a new web console release:
We fixed two issues:
https://issues.apache.org/jira/browse/FELIX/fixforversion/12333546

Staging repositories:
https://repository.apache.org/content/repositories/orgapachefelix-1097/

You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 10697 /tmp/felix-staging

Please vote to approve this release:

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

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

[jira] [Created] (FELIX-5060) Unnecessary import of org.osgi.service.component

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created FELIX-5060:
---

 Summary: Unnecessary import of org.osgi.service.component
 Key: FELIX-5060
 URL: https://issues.apache.org/jira/browse/FELIX-5060
 Project: Felix
  Issue Type: Bug
  Components: Web Console
Affects Versions: webconsole-4.2.12
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: webconsole-4.2.14


For an unknown reason the webconsole has an import to 
org.osgi.service.component which it should not have as no code is using DS 
within the webconsole



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FELIX-5060) Unnecessary import of org.osgi.service.component

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-5060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved FELIX-5060.
-
Resolution: Fixed

Nothing to commit as the import is not there anymore. I assume something went 
wrong with the 4.2.12 release

> Unnecessary import of org.osgi.service.component
> 
>
> Key: FELIX-5060
> URL: https://issues.apache.org/jira/browse/FELIX-5060
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Affects Versions: webconsole-4.2.12
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: webconsole-4.2.14
>
>
> For an unknown reason the webconsole has an import to 
> org.osgi.service.component which it should not have as no code is using DS 
> within the webconsole



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

[davidb]

Here's my +1

David

On 1 October 2015 at 10:42,   wrote:
> Hi all,
>
> I'm calling a vote on the following bundles:
>
> Felix Gogo Shell 0.12.0
> ** Improvement
> * FELIX-5021 [GOGO] Use system bundle to find bundles
> * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
> a bundle fragment
> * FELIX-3341 Simple csh-like Command History
> * FELIX-3340 Allow the prompt to be a Function
>
> ** Bug
> * FELIX-4425 Short command in Gogo Shell not working with Java 8
> * FELIX-3706 gogo shell startup failure in busy system
> * FELIX-3703 Race condition in gogo runtime activator
>
> Felix Gogo Command 0.16.0
> ** Improvement
> * FELIX-5021 [GOGO] Use system bundle to find bundles
> * FELIX-5009 Relative URIs would be nice for install and update
> * FELIX-5008 gogo usage messages could be less confusing
> * FELIX-3499 felix:cd command works only with relative paths
>
> ** Bug
> * FELIX-4969 cd refuses to leave initial directory
>
> Note that not changes have been made to the Felix Gogo Runtime bundle
> since the last release.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1096
>
> You can use this UNIX script to download the release and verify the 
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 1096 /tmp/felix-gogo-check
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will remain open for at least 72 hours.
>
> Best regards,
>
> David Bosschaert

[jira] [Resolved] (FELIX-3104) Registering/unregistering HttpService with CometdServiceImpl repeatedly causes ClassCastException

[Carsten Ziegeler (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Carsten Ziegeler resolved FELIX-3104.
-
Resolution: Won't Fix

> Registering/unregistering HttpService with CometdServiceImpl repeatedly 
> causes ClassCastException
> -
>
> Key: FELIX-3104
> URL: https://issues.apache.org/jira/browse/FELIX-3104
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Julian Sedding
>Assignee: Felix Meschberger
>Priority: Minor
> Attachments: FELIX-3104-fmeschbe.patch, FELIX-3104.patch
>
>
> CometdServiceImpl uses 
> org.mortbay.cometd.continuation.ContinuationCometdServlet in its 
> implementation, which in turn extends 
> org.mortbay.cometd.AbstractCometdServlet. AbstractCometdServlet places a 
> Bayeux object in a servlet context attribute in its init() method, but never 
> cleans it up on destroy(). This can lead to a ClassCastException if the 
> servlet's init() method is called repeatedly, and the ClassLoader used to 
> create the object stored in the servlet context attribute is not the same 
> that was used to load the AbstractCometdServlet class. However, this is what 
> seems to happen if the cometd bundle is restarted (may only be the case with 
> the patch from FELIX-3102 applied).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-3104) Registering/unregistering HttpService with CometdServiceImpl repeatedly causes ClassCastException

[Julian Sedding (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940943#comment-14940943
 ] 

Julian Sedding commented on FELIX-3104:
---

[~cziegeler] I don't know. I have not used Cometd since 2011. I'm fine with 
closing this issue. If someone stumbles over the same issue, it can always be 
re-opened.

> Registering/unregistering HttpService with CometdServiceImpl repeatedly 
> causes ClassCastException
> -
>
> Key: FELIX-3104
> URL: https://issues.apache.org/jira/browse/FELIX-3104
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Affects Versions: http-2.2.0
>Reporter: Julian Sedding
>Assignee: Felix Meschberger
>Priority: Minor
> Attachments: FELIX-3104-fmeschbe.patch, FELIX-3104.patch
>
>
> CometdServiceImpl uses 
> org.mortbay.cometd.continuation.ContinuationCometdServlet in its 
> implementation, which in turn extends 
> org.mortbay.cometd.AbstractCometdServlet. AbstractCometdServlet places a 
> Bayeux object in a servlet context attribute in its init() method, but never 
> cleans it up on destroy(). This can lead to a ClassCastException if the 
> servlet's init() method is called repeatedly, and the ClassLoader used to 
> create the object stored in the servlet context attribute is not the same 
> that was used to load the AbstractCometdServlet class. However, this is what 
> seems to happen if the cometd bundle is restarted (may only be the case with 
> the patch from FELIX-3102 applied).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4923) SslFilterResponse doesn 't take in account ssl-forward.header property

[Antonio Sanso (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940863#comment-14940863
 ] 

Antonio Sanso commented on FELIX-4923:
--

Sure. I'll propose a patch...

> SslFilterResponse doesn 't take in account ssl-forward.header property
> --
>
> Key: FELIX-4923
> URL: https://issues.apache.org/jira/browse/FELIX-4923
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Antonio Sanso
>Priority: Minor
>
> {{SslFilterResponse}} doesn 't take in account {{ssl-forward}}.header 
> property.
> Indeed the {{SslFilterResponse}} constructor hardcodes 
> {{HDR_X_FORWARDED_PROTO}}.
> {code}
> ...
> request.getHeader(HDR_X_FORWARDED_PROTO);
> ...
> {code}
> the  {{ssl-forward}} osgin configuration should be taken in account IMHO. The 
> default is even different than {{HDR_X_FORWARDED_PROTO}} indeed is rather 
> {{X-Forwarded-SSL}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (FELIX-4923) SslFilterResponse doesn 't take in account ssl-forward.header property

[Carsten Ziegeler (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-4923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940851#comment-14940851
 ] 

Carsten Ziegeler commented on FELIX-4923:
-

[~asanso] If I understand the code correctly, X-Forwaded-SSL is checked to see 
whether the filter should run at all, and then the harded headers are used to 
get the protocol and the port. Not sure if that makes sense or not. In any 
case, care to make a patch?

> SslFilterResponse doesn 't take in account ssl-forward.header property
> --
>
> Key: FELIX-4923
> URL: https://issues.apache.org/jira/browse/FELIX-4923
> Project: Felix
>  Issue Type: Bug
>  Components: HTTP Service
>Reporter: Antonio Sanso
>Priority: Minor
>
> {{SslFilterResponse}} doesn 't take in account {{ssl-forward}}.header 
> property.
> Indeed the {{SslFilterResponse}} constructor hardcodes 
> {{HDR_X_FORWARDED_PROTO}}.
> {code}
> ...
> request.getHeader(HDR_X_FORWARDED_PROTO);
> ...
> {code}
> the  {{ssl-forward}} osgin configuration should be taken in account IMHO. The 
> default is even different than {{HDR_X_FORWARDED_PROTO}} indeed is rather 
> {{X-Forwarded-SSL}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (FELIX-1963) Add possibility to share ServletContext between bundles

[Sten Roger Sandvik (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FELIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sten Roger Sandvik closed FELIX-1963.
-
Resolution: Fixed

> Add possibility to share ServletContext between bundles
> ---
>
> Key: FELIX-1963
> URL: https://issues.apache.org/jira/browse/FELIX-1963
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Affects Versions: http-2.0.4
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
>
> Check out the possibility to share ServletContext between bundles. If 
> ServletContextManager is global instead of local to each bundle then it 
> chould be done. If you want to share ServletContext each HttpContext must 
> implement equals method that ensures equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Apache Felix Gogo Shell 0.12.0 and Command 0.16.0

[Jean-Baptiste Onofré]

+1 (non binding)

Regards
JB

On 10/01/2015 10:42 AM, dav...@apache.org wrote:

Hi all,

I'm calling a vote on the following bundles:

Felix Gogo Shell 0.12.0
** Improvement
 * FELIX-5021 [GOGO] Use system bundle to find bundles
 * FELIX-4529 [Gogo] Let gosh be configured by files contributed by
a bundle fragment
 * FELIX-3341 Simple csh-like Command History
 * FELIX-3340 Allow the prompt to be a Function

** Bug
 * FELIX-4425 Short command in Gogo Shell not working with Java 8
 * FELIX-3706 gogo shell startup failure in busy system
 * FELIX-3703 Race condition in gogo runtime activator

Felix Gogo Command 0.16.0
** Improvement
 * FELIX-5021 [GOGO] Use system bundle to find bundles
 * FELIX-5009 Relative URIs would be nice for install and update
 * FELIX-5008 gogo usage messages could be less confusing
 * FELIX-3499 felix:cd command works only with relative paths

** Bug
 * FELIX-4969 cd refuses to leave initial directory

Note that not changes have been made to the Felix Gogo Runtime bundle
since the last release.

Staging repository:
https://repository.apache.org/content/repositories/orgapachefelix-1096

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 1096 /tmp/felix-gogo-check

Please vote to approve this release:

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

This vote will remain open for at least 72 hours.

Best regards,

David Bosschaert



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

[jira] [Commented] (FELIX-1963) Add possibility to share ServletContext between bundles

[Sten Roger Sandvik (JIRA)]

[ 
https://issues.apache.org/jira/browse/FELIX-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940839#comment-14940839
 ] 

Sten Roger Sandvik commented on FELIX-1963:
---

No, it seems to be working with the new whiteboard implementation. We can close 
this one.

> Add possibility to share ServletContext between bundles
> ---
>
> Key: FELIX-1963
> URL: https://issues.apache.org/jira/browse/FELIX-1963
> Project: Felix
>  Issue Type: New Feature
>  Components: HTTP Service
>Affects Versions: http-2.0.4
>Reporter: Sten Roger Sandvik
>Assignee: Sten Roger Sandvik
>
> Check out the possibility to share ServletContext between bundles. If 
> ServletContextManager is global instead of local to each bundle then it 
> chould be done. If you want to share ServletContext each HttpContext must 
> implement equals method that ensures equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)