Re: [VOTE] Release Aries JMX components (take 2)

[Jean-Baptiste Onofré]

+1 (binding)

Agree to not release uber bundles anymore (it's some changes to do in Karaf, but 
not a big deal).


Regards
JB

On 01/02/2018 02:10 PM, David Bosschaert wrote:

Hi all,

I'm calling a vote on various Aries JMX components, now with versions
updated from 1.2 to 1.2.0.
The org.apache.aries.jmx.api component has not changed since the last
release and is thus not included in this set.

org.apache.aries.jmx.core version 1.1.8
org.apache.aries.jmx.core.whiteboard version 1.1.6
[ARIES-1630] jmx core fails if configadmin is not present

org.apache.aries.jmx.blueprint.api version 1.2.0
org.apache.aries.jmx.blueprint.core version 1.2.0
[ARIES-1707] BlueprintMetadata.getBlueprintContainer throws inconsistent
exceptions

org.apache.aries.jmx.whiteboard version 1.2.0
[ARIES-1766] Configure log severity for Whiteboard JMX registration
exceptions
[ARIES-1630] jmx core fails if configadmin is not present

Staging repository:
https://repository.apache.org/content/repositories/orgapachearies-1123

Please vote:

  +1 Approve the release
  -1 Do not approve the release (please explain why)

This vote will be 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

Re: [VOTE] Release Aries JMX components (take 2)

[David Bosschaert]

Here's my +1

David

On 2 January 2018 at 13:10, David Bosschaert 
wrote:

> Hi all,
>
> I'm calling a vote on various Aries JMX components, now with versions
> updated from 1.2 to 1.2.0.
> The org.apache.aries.jmx.api component has not changed since the last
> release and is thus not included in this set.
>
> org.apache.aries.jmx.core version 1.1.8
> org.apache.aries.jmx.core.whiteboard version 1.1.6
> [ARIES-1630] jmx core fails if configadmin is not present
>
> org.apache.aries.jmx.blueprint.api version 1.2.0
> org.apache.aries.jmx.blueprint.core version 1.2.0
> [ARIES-1707] BlueprintMetadata.getBlueprintContainer throws inconsistent
> exceptions
>
> org.apache.aries.jmx.whiteboard version 1.2.0
> [ARIES-1766] Configure log severity for Whiteboard JMX registration
> exceptions
> [ARIES-1630] jmx core fails if configadmin is not present
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachearies-1123
>
> Please vote:
>
>  +1 Approve the release
>  -1 Do not approve the release (please explain why)
>
> This vote will be open for at least 72 hours.
>
> Best regards,
>
> David Bosschaert
>

Re: Aries Spec Jars

[Timothy Ward]

I’m still not sure what the eventual resolution of this discussion will be as 
it may be that Aries implementation needs simply cannot be met by using the 
Service Mix spec bundles, however I do agree that we should be fixing up 
Service Mix API bundles as far as we can. To that end I have created a PR for 
JSONP (https://github.com/apache/servicemix-specs/pull/12) which is not 
currently present in Aries, and is needed for JAX-RS support.

Tim


On 22 Dec 2017, at 17:42, Daniel Kulp 
> wrote:



On Dec 22, 2017, at 10:30 AM, Raymond Auge 
> wrote:

Do those spec bundles also exist over in SMX or Geronimo?   Is there a
“significant” number of major Apache projects that are currently using
either the ones in Aries or the ones in ServiceMix/Geronimo?   If so, then
yea, we should remove them.   Stop duplicating stuff and, instead, get
issues fixed.


I don't think this is feasible.

The reason being that those projects are using those API jars coming from a
different perspective.

Their perspective is:

- Make the API usable in OSGi when there is no OSGi specification which
specifies it's use.

I disagree..It’s just “Make the API usable in OSGi”, period.

If there is a spec, great.  If there isn’t still make it work.  Almost as 
importantly: make it work in cases where the spec is available (new runtime) as 
well as not available (old runtimes).


From that perspective they are free to make implementation choices which is
totally fine for that case. However those choices are proprietary.

…  and, for the most part, hidden.


That’s fine as a proposal, but there are a *lot* of fixes needed in
ServiceMix before the bundles are usable. None of the bundles offer (as far
as I can tell) offer the correct contract capability (or even any contract
at all), and they all seem to include a custom locator which isn’t part of
the original specification jar. This locator will have unknown effects on
specification implementations and may need to be removed. Are the
ServiceMix team really going to be ok with changes that radical,
particularly when they affect existing released artifacts?

Removing the Locator stuff is likely not going to fly, adding additional
bundle headers is likely OK.


Here you've now made it impossible by first saying that all changes should
be made in servicemix BUT that you won't accept the changes in servicemix!

I didn’t say that at all…. I said changes can be be made in ServiceMix, but 
keeping the locator (or some similar mechanism) to make sure the API’s continue 
to work correctly is important. If updating the FactoryFinders to use the 
locator if the “standard osgi mechanism” fails is necessary, that SHOULD be 
fine.


You're not leaving us with many options.

The locator stuff is a proprietary detail that is not part of the OSGi
specification for how these APIs should be used.

And is a completely hidden, private package and thus nearly irrelevant.


CXF does NOT implement the upcoming OSGi JAX-RS specification which is what
we're talking about here. And therefore CXF can't be placed in the same
category with the Aries JAX-RS and Aries in general which is about
implementing specifications.

Don't get me wrong, CXF and ServiceMix are fine projects. However they are
not implementing specifications. They are purely industry implementations
and those implementations have made design choices which are more or less
incompatible with the upcoming OSGi specification.

CXF implements a ton of specs… a future OSGi JAX-RS spec may or may not become 
one of them.In particular, I can definitely see CXF registering the various 
builders and such as OSGi services.


I sincerely hope you re-consider your position and offer some real help
otherwise we're stuck not being able to deliver RIs for OSGi R7.

I *AM* offering help…. I’m more than willing to do some work and apply patches 
or whatever in the ServiceMix specs to get it updated and usable.

For now, as a test, I added the Provide-Capability stuff into the smx bundle, 
updated the maven-bundle-plugin to understand it,  and updated all of the 
aries-jax-rs-whiteboard poms/bndrun files to use it instead of the local thing 
and all the tests pass.   Thus, I’m back to “why add another one” and "why can 
it not work for the RI?"


Dan




- Ray



Dan





Regards,

Tim

On 21 Dec 2017, at 18:16, Daniel Kulp 
> wrote:



On Dec 21, 2017, at 1:00 PM, Raymond Auge 
<
mailto:raymond.a...@liferay.com>> wrote:

On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp 
mailto:dk...@apache.org>>> wrote:

Can I ask why the spec/api bundles that are provided by ServiceMix are
not
usable?   Could the ServiceMix api bundles be updated to make them
usable?


Most of the ServiceMix jars violate the terms