[jira] [Updated] (FELIX-5791) Support OSGi R7 framework features

2018-02-23 Thread Karl Pauls (JIRA) 

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

Karl Pauls updated FELIX-5791:
--
Description: 
Now that the R7 spec is completed we need to look into getting the framework to 
support R7.

Development will be done against the copy in the osgi-r7 sub dir for now.

  was:Now that the R7 spec is completed we need to look into getting the 
framework to support R7.


> Support OSGi R7 framework features
> --
>
> Key: FELIX-5791
> URL: https://issues.apache.org/jira/browse/FELIX-5791
> Project: Felix
>  Issue Type: New Feature
>  Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.0
>
>
> Now that the R7 spec is completed we need to look into getting the framework 
> to support R7.
> Development will be done against the copy in the osgi-r7 sub dir for now.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (FELIX-5791) Support OSGi R7 framework features

2018-02-23 Thread Karl Pauls (JIRA) 

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

Karl Pauls updated FELIX-5791:
--
Description: 
Now that the R7 spec is completed we need to look into getting the framework to 
support R7.

Development will be done against the copy in the osgi-r7 sub dir for now. The 
update of the osgi classes and the switch to the resolver supporting R7 has 
already been done in the initial copy commit.

  was:
Now that the R7 spec is completed we need to look into getting the framework to 
support R7.

Development will be done against the copy in the osgi-r7 sub dir for now.


> Support OSGi R7 framework features
> --
>
> Key: FELIX-5791
> URL: https://issues.apache.org/jira/browse/FELIX-5791
> Project: Felix
>  Issue Type: New Feature
>  Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.0
>
>
> Now that the R7 spec is completed we need to look into getting the framework 
> to support R7.
> Development will be done against the copy in the osgi-r7 sub dir for now. The 
> update of the osgi classes and the switch to the resolver supporting R7 has 
> already been done in the initial copy commit.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5792) Implement java.* import and exports

2018-02-23 Thread Karl Pauls (JIRA) 

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

Karl Pauls commented on FELIX-5792:
---

I added support for this in r1825179.

> Implement java.* import and exports
> ---
>
> Key: FELIX-5792
> URL: https://issues.apache.org/jira/browse/FELIX-5792
> Project: Felix
>  Issue Type: Sub-task
>  Components: Framework
>Affects Versions: framework-5.6.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.0
>
>
> The spec now allows to import java.* and requires the framework to export 
> available java.* packages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5792) Implement java.* import and exports

2018-02-23 Thread Karl Pauls (JIRA) 
Karl Pauls created FELIX-5792:
-

 Summary: Implement java.* import and exports
 Key: FELIX-5792
 URL: https://issues.apache.org/jira/browse/FELIX-5792
 Project: Felix
  Issue Type: Sub-task
  Components: Framework
Affects Versions: framework-5.6.10
Reporter: Karl Pauls
Assignee: Karl Pauls
 Fix For: framework-6.0.0


The spec now allows to import java.* and requires the framework to export 
available java.* packages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (FELIX-5791) Support OSGi R7 framework features

2018-02-23 Thread Karl Pauls (JIRA) 
Karl Pauls created FELIX-5791:
-

 Summary: Support OSGi R7 framework features
 Key: FELIX-5791
 URL: https://issues.apache.org/jira/browse/FELIX-5791
 Project: Felix
  Issue Type: New Feature
  Components: Framework
Affects Versions: framework-5.6.10
Reporter: Karl Pauls
Assignee: Karl Pauls
 Fix For: framework-6.0.0


Now that the R7 spec is completed we need to look into getting the framework to 
support R7.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread JIRA 

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

Raymond Augé commented on FELIX-5782:
-

See the updated PR https://github.com/apache/felix/pull/132

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread JIRA 

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

Raymond Augé commented on FELIX-5782:
-

great, i will make this change.

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread Thomas Watson (JIRA) 

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

Thomas Watson commented on FELIX-5782:
--

+1 to creating an enum Reason and single exception type.  I think this is more 
likely to be how we would do it for the specification if we want to push for it 
there.

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread JIRA 

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

Raymond Augé commented on FELIX-5782:
-

I could take that approach if you prefer.

How about:

{code}
class abstract ResolutionFailureException extends ResolutionException {
 public enum Reason \{ DynamicImport, FragmentNotSelected, 
MissingRequirement, UseConstraint }

 public abstract Reason getReason();
}
{code}

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread JIRA 

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

Raymond Augé edited comment on FELIX-5782 at 2/23/18 6:46 PM:
--

I could take that approach if you prefer.

How about:
{code:java}
class abstract ResolutionFailureException extends ResolutionException {
 public enum Reason { DynamicImport, FragmentNotSelected, 
MissingRequirement, UseConstraint }

 public abstract Reason getReason();
}
{code}


was (Author: rotty3000):
I could take that approach if you prefer.

How about:

{code}
class abstract ResolutionFailureException extends ResolutionException {
 public enum Reason \{ DynamicImport, FragmentNotSelected, 
MissingRequirement, UseConstraint }

 public abstract Reason getReason();
}
{code}

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Apache Felix Web Console Memory Usage Plugin 1.0.8

2018-02-23 Thread Pierre De Rop 
Hi

+1

thanks
Pierre

On Thu, Feb 22, 2018 at 3:35 PM, Francois Papon <
francois.pa...@openobject.fr> wrote:

> +1 (non-binding)
>
> Francois
>
>
> Le 22/02/2018 à 18:07, Karl Pauls a écrit :
> > I would like to call a vote on the following subproject release:
> >
> > Apache Felix Web Console Memory Usage Plugin 1.0.8
> >
> > We solved 3 issues in this release
> > https://issues.apache.org/jira/projects/FELIX/versions/12332164
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachefelix-1214/
> >
> > 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 1214 /tmp/felix-staging
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
>
>

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread Richard S. Hall (JIRA) 

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

Richard S. Hall commented on FELIX-5782:


Looking at this latest patch, it makes it a little more obvious to ask, why we 
are creating lots of different exception classes as opposed to adding a single 
extended exception with a "reason" method?

Especially, if in the future, you thought about adding more diagnostics (not 
that we will want to or should) which would have to be duplicated across all of 
these exceptions.

In general, I try to avoid creating lots of classes.

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: FELIX-5782

2018-02-23 Thread Raymond Auge 
As you can see I've made some changes based on Tom's feedback:

- the exceptions are lazily created once again
- the exception types are stupid simple and so cannot bleed impl details
- there's javadoc on each type

Cheers,
- Ray

On Fri, Feb 23, 2018 at 10:59 AM, Thomas Watson  wrote:

> See my comments in the issue.
>
> Tom
>
> On Fri, Feb 23, 2018 at 9:16 AM, Raymond Auge 
> wrote:
>
> > Hello All,
> >
> > I'd like to get some feedback particularly from Richard Hall, Thomas
> Watson
> > and/or Karl Pauls regarding the change described in
> > https://issues.apache.org/jira/browse/FELIX-5782
> >
> > Is there any reason I cannot merge this change? I'd like to get this in
> and
> > call a vote for a release of the resolver next week so we can apply it to
> > bnd. I'll take no feedback as not having issues if that's ok :)
> >
> > Sincerely,
> > --
> > *Raymond Augé* 
> >  (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* 
> >  (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance 
> > (@OSGiAlliance)
> >
>



-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[GitHub] felix pull request #132: FELIX-5782 allow resolver errors to be introspected

2018-02-23 Thread rotty3000 
GitHub user rotty3000 opened a pull request:

https://github.com/apache/felix/pull/132

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rotty3000/felix resolver.introspection

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/132.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #132


commit a9ed345c6fb0d9cab23c6e7189728766ef114d61
Author: Raymond Augé 
Date:   2018-01-31T20:31:18Z

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 




---

[GitHub] felix pull request #131: FELIX-5782 allow resolver errors to be introspected

2018-02-23 Thread rotty3000 
Github user rotty3000 closed the pull request at:

https://github.com/apache/felix/pull/131


---

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on FELIX-5782:
---

GitHub user rotty3000 opened a pull request:

https://github.com/apache/felix/pull/132

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/rotty3000/felix resolver.introspection

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/132.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #132


commit a9ed345c6fb0d9cab23c6e7189728766ef114d61
Author: Raymond Augé 
Date:   2018-01-31T20:31:18Z

FELIX-5782 allow resolver errors to be introspected

Signed-off-by: Raymond Augé 




> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on FELIX-5782:
---

Github user rotty3000 closed the pull request at:

https://github.com/apache/felix/pull/131


> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread JIRA 

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

Raymond Augé commented on FELIX-5782:
-

> 1. You now eagerly create ResolutionExceptions during all phases of 
> resolution.  I know as part of a performance improvement Guillaume did was to 
> avoid this.  I would prefer to keep the usage ResolutionError unchanged in 
> the resolver implementation and perhaps make ResolutionError.toException() be 
> abstract such that each ResolutionError implementation can return specific 
> ResolutionException types when we go to throw the exception.

I'll try this.

> 2. I would like to see some javadoc on these specific exception types now 
> since you seem to be introducing new API of sorts here.

Sure thing, I just didn't want to do all that work if there wasn't consensus.

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: FELIX-5782

2018-02-23 Thread Thomas Watson 
See my comments in the issue.

Tom

On Fri, Feb 23, 2018 at 9:16 AM, Raymond Auge 
wrote:

> Hello All,
>
> I'd like to get some feedback particularly from Richard Hall, Thomas Watson
> and/or Karl Pauls regarding the change described in
> https://issues.apache.org/jira/browse/FELIX-5782
>
> Is there any reason I cannot merge this change? I'd like to get this in and
> call a vote for a release of the resolver next week so we can apply it to
> bnd. I'll take no feedback as not having issues if that's ok :)
>
> Sincerely,
> --
> *Raymond Augé* 
>  (@rotty3000)
> Senior Software Architect *Liferay, Inc.* 
>  (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance 
> (@OSGiAlliance)
>

[jira] [Commented] (FELIX-5782) allow resolver errors to be introspected

2018-02-23 Thread Thomas Watson (JIRA) 

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

Thomas Watson commented on FELIX-5782:
--

Two comments
 # You now eagerly create ResolutionExceptions during all phases of resolution. 
 I know as part of a performance improvement Guillaume did was to avoid this.  
I would prefer to keep the usage ResolutionError unchanged in the resolver 
implementation and perhaps make ResolutionError.toException() be abstract such 
that each ResolutionError implementation can return specific 
ResolutionException types when we go to throw the exception.
 # I would like to see some javadoc on these specific exception types now since 
you seem to be introducing new API of sorts here.

> allow resolver errors to be introspected
> 
>
> Key: FELIX-5782
> URL: https://issues.apache.org/jira/browse/FELIX-5782
> Project: Felix
>  Issue Type: Improvement
>  Components: Resolver
>Reporter: Raymond Augé
>Assignee: Thomas Watson
>Priority: Minor
>
> The current model for resolver errors does not provide any means of 
> introspecting deeper knowledge that the resolver gained. The information is 
> internal only, which makes user feedback more difficult to produce than 
> necessary.
> I propose to expose the error types by means of an exported package 
> {{org.apache.felix.resolver.error}}. This will allow interested clients to 
> dig more deeply into the reasons for resolution failure in order to provide 
> better feedback to users.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: FELIX-5782

2018-02-23 Thread Richard S. Hall 
Clearly, this will only be of interest to a very small number of people, 
but that's probably also true of the resolver API in general.


Regardless, the patch itself seems reasonably harmless, so I don't have 
any technical issues with it as an implementation detail. In general, 
though, we try to shy away from creating special Felix API, so I 
wouldn't want to create a trend...


Of course, Tom is much more involved in resolver maintenance these days, 
so I'd prefer his explicit signoff if possible.


-> richard

On 2/23/18 10:16 , Raymond Auge wrote:

Hello All,

I'd like to get some feedback particularly from Richard Hall, Thomas Watson
and/or Karl Pauls regarding the change described in
https://issues.apache.org/jira/browse/FELIX-5782

Is there any reason I cannot merge this change? I'd like to get this in and
call a vote for a release of the resolver next week so we can apply it to
bnd. I'll take no feedback as not having issues if that's ok :)

Sincerely,

FELIX-5782

2018-02-23 Thread Raymond Auge 
Hello All,

I'd like to get some feedback particularly from Richard Hall, Thomas Watson
and/or Karl Pauls regarding the change described in
https://issues.apache.org/jira/browse/FELIX-5782

Is there any reason I cannot merge this change? I'd like to get this in and
call a vote for a release of the resolver next week so we can apply it to
bnd. I'll take no feedback as not having issues if that's ok :)

Sincerely,
-- 
*Raymond Augé* 
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* 
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance  (@OSGiAlliance)

[jira] [Created] (FELIX-5790) Improve procedural function syntax

2018-02-23 Thread Guillaume Nodet (JIRA) 
Guillaume Nodet created FELIX-5790:
--

 Summary: Improve procedural function syntax
 Key: FELIX-5790
 URL: https://issues.apache.org/jira/browse/FELIX-5790
 Project: Felix
  Issue Type: Improvement
  Components: Gogo JLine
Reporter: Guillaume Nodet


The procedural functions can be made more user friendly:
{code}
each {1..10} do { xxx }
if { condition } then { action } elif { another action } else { else action }
try { code } catch { catch-action } finally { finally-action }
while { condition } do { action }
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)