You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Timothy Ward <ti...@apache.org> on 2017/12/21 11:25:26 UTC
Aries Spec Jars
Hi all,
I’ve noticed that an increasing number of Aries projects are producing wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this is a good thing, as few other Open Source projects package the jars with OSGi contract metadata.
I do wonder, however, if these spec jars should be provided by a separate Aries project, rather than scattered across multiple other projects. I have two main reasons for this.
1. It makes the code for packaging the spec jars harder to find in source control
2. It creates some non-obvious links between projects. It’s clear why tx-control depends on JPA, but not why JAX-RS depends on CDI!
The spec jars are mostly being put into a separate Maven group already. I would simply see this as a formalisation of that earlier decision.
Thoughts?
Tim
Sent from my iPhone
Re: Aries Spec Jars
Posted by David Jencks <da...@gmail.com>.
Another alternative might be to use the Geronimo spec jars and make sure the included osgi metadata is correct.
David Jencks
Sent from my iPhone
> On Dec 21, 2017, at 6:28 AM, Raymond Auge <ra...@liferay.com> wrote:
>
> Hi Tim,
>
> I was thinking of proposing this very thing over the last few weeks.
>
> I had already deliberately pushed the CDI related spec jars and also the
> spec jar for JAX-RS into an aries sub-group in maven in order to better
> accommodate and reflect this very thing.
>
> So, I would be a big +1 for having these in a specific sub-project.
>
> - Ray
>
> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>
> wrote:
>
>> Hi all,
>>
>> I’ve noticed that an increasing number of Aries projects are producing
>> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this is a
>> good thing, as few other Open Source projects package the jars with OSGi
>> contract metadata.
>>
>> I do wonder, however, if these spec jars should be provided by a separate
>> Aries project, rather than scattered across multiple other projects. I have
>> two main reasons for this.
>>
>> 1. It makes the code for packaging the spec jars harder to find in source
>> control
>>
>> 2. It creates some non-obvious links between projects. It’s clear why
>> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>>
>> The spec jars are mostly being put into a separate Maven group already. I
>> would simply see this as a formalisation of that earlier decision.
>>
>> Thoughts?
>>
>> Tim
>>
>> Sent from my iPhone
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: Aries Spec Jars
Posted by Timothy Ward <ti...@apache.org>.
My mail client appears to have messed up the indenting, sorry about that. I hope that people can still make sense of the previous mail.
Tim
> On 22 Dec 2017, at 09:14, Timothy Ward <ti...@apache.org> wrote:
>
> I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects.
>
> Well we already do have working spec bundles here at Aries (and have had for quite some time), so is your proposal to remove them?
>
> 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?
>
> As Ray points out the licensing also needs to be fixed before any of the bundles can be used in an OSGi reference implementation (which affects at least Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA). The reference implementations also need to be ready for the R7 release in the next month or so. My original suggestion was a simple movement of the existing bundles, do we have a different solution that’s workable in that time-frame?
>
> Regards,
>
> Tim
>
> On 21 Dec 2017, at 18:16, Daniel Kulp <dk...@apache.org>> wrote:
>
>
>
> On Dec 21, 2017, at 1:00 PM, Raymond Auge <ra...@liferay.com>> wrote:
>
> On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <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 of the original license of
> the specification artifacts they touch. They also violate the Apache
> guidelines for repackaging such artifacts.
>
> I personally didn't have the stomach to repair the ones we needed in that
> project so opted to fix them in Aries.
>
> If we could get them fixed then that might be a solution.
>
>
> Submit a patch! I can get them applied there easily enough. I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects.
>
> Dan
>
>
>
>
>
>
> - Ray
>
>
>
> I really would prefer not getting into a situation where we have a bunch
> of project that are commonly used together starting to pull in multiple
> versions or implementations of the same bundles. For example: CXF uses
> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
> which would obviously result in multiple bundles exporting the same
> package/versions.
>
> Dan
>
>
>
> On Dec 21, 2017, at 9:28 AM, Raymond Auge <ra...@liferay.com>>
> wrote:
>
> Hi Tim,
>
> I was thinking of proposing this very thing over the last few weeks.
>
> I had already deliberately pushed the CDI related spec jars and also the
> spec jar for JAX-RS into an aries sub-group in maven in order to better
> accommodate and reflect this very thing.
>
> So, I would be a big +1 for having these in a specific sub-project.
>
> - Ray
>
> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>>
> wrote:
>
> Hi all,
>
> I’ve noticed that an increasing number of Aries projects are producing
> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
> is a
> good thing, as few other Open Source projects package the jars with OSGi
> contract metadata.
>
> I do wonder, however, if these spec jars should be provided by a
> separate
> Aries project, rather than scattered across multiple other projects. I
> have
> two main reasons for this.
>
> 1. It makes the code for packaging the spec jars harder to find in
> source
> control
>
> 2. It creates some non-obvious links between projects. It’s clear why
> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>
> The spec jars are mostly being put into a separate Maven group already.
> I
> would simply see this as a formalisation of that earlier decision.
>
> Thoughts?
>
> Tim
>
> Sent from my iPhone
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
> --
> Daniel Kulp
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
>
> --
> Daniel Kulp
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com<http://coders.talend.com/>
>
Re: Aries Spec Jars
Posted by Christian Schneider <ch...@die-schneider.net>.
How about fixing the servicemix bundles in a branch and maybe even release
a version from the branch to cope with the narrow time frame.
So the specs bundles still live in servicemix and it is easier to
consolidate them into one common version again.
Christian
2017-12-22 10:14 GMT+01:00 Timothy Ward <ti...@apache.org>:
> I’m completely against having yet another bundle here when the other
> bundles are the ones that will be be used by all the other projects.
>
> Well we already do have working spec bundles here at Aries (and have had
> for quite some time), so is your proposal to remove them?
>
> 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?
>
> As Ray points out the licensing also needs to be fixed before any of the
> bundles can be used in an OSGi reference implementation (which affects at
> least Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA).
> The reference implementations also need to be ready for the R7 release in
> the next month or so. My original suggestion was a simple movement of the
> existing bundles, do we have a different solution that’s workable in that
> time-frame?
>
> Regards,
>
> Tim
>
> On 21 Dec 2017, at 18:16, Daniel Kulp <dkulp@apache.org<mailto:dkulp
> @apache.org>> wrote:
>
>
>
> On Dec 21, 2017, at 1:00 PM, Raymond Auge <raymond.auge@liferay.com<
> mailto:raymond.auge@liferay.com>> wrote:
>
> On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <dkulp@apache.org<mailto:
> dkulp@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 of the original license of
> the specification artifacts they touch. They also violate the Apache
> guidelines for repackaging such artifacts.
>
> I personally didn't have the stomach to repair the ones we needed in that
> project so opted to fix them in Aries.
>
> If we could get them fixed then that might be a solution.
>
>
> Submit a patch! I can get them applied there easily enough. I’m
> completely against having yet another bundle here when the other bundles
> are the ones that will be be used by all the other projects.
>
> Dan
>
>
>
>
>
>
> - Ray
>
>
>
> I really would prefer not getting into a situation where we have a bunch
> of project that are commonly used together starting to pull in multiple
> versions or implementations of the same bundles. For example: CXF uses
> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
> which would obviously result in multiple bundles exporting the same
> package/versions.
>
> Dan
>
>
>
> On Dec 21, 2017, at 9:28 AM, Raymond Auge <raymond.auge@liferay.com<
> mailto:raymond.auge@liferay.com>>
> wrote:
>
> Hi Tim,
>
> I was thinking of proposing this very thing over the last few weeks.
>
> I had already deliberately pushed the CDI related spec jars and also the
> spec jar for JAX-RS into an aries sub-group in maven in order to better
> accommodate and reflect this very thing.
>
> So, I would be a big +1 for having these in a specific sub-project.
>
> - Ray
>
> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <timothyjward@apache.org<
> mailto:timothyjward@apache.org>>
> wrote:
>
> Hi all,
>
> I’ve noticed that an increasing number of Aries projects are producing
> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
> is a
> good thing, as few other Open Source projects package the jars with OSGi
> contract metadata.
>
> I do wonder, however, if these spec jars should be provided by a
> separate
> Aries project, rather than scattered across multiple other projects. I
> have
> two main reasons for this.
>
> 1. It makes the code for packaging the spec jars harder to find in
> source
> control
>
> 2. It creates some non-obvious links between projects. It’s clear why
> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>
> The spec jars are mostly being put into a separate Maven group already.
> I
> would simply see this as a formalisation of that earlier decision.
>
> Thoughts?
>
> Tim
>
> Sent from my iPhone
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
> --
> Daniel Kulp
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
> --
> Daniel Kulp
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com<http:
> //coders.talend.com/>
>
>
--
--
Christian Schneider
http://www.liquid-reality.de
Computer Scientist
http://www.adobe.com
Re: Aries Spec Jars
Posted by Timothy Ward <ti...@apache.org>.
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 <dk...@apache.org>> wrote:
On Dec 22, 2017, at 10:30 AM, Raymond Auge <ra...@liferay.com>> 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 <dk...@apache.org><mailto:dkulp
@apache.org>> wrote:
On Dec 21, 2017, at 1:00 PM, Raymond Auge <ra...@liferay.com><
mailto:raymond.auge@liferay.com>> wrote:
On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <dk...@apache.org><mailto:
dkulp@apache.org<ma...@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 of the original license of
the specification artifacts they touch. They also violate the Apache
guidelines for repackaging such artifacts.
I personally didn't have the stomach to repair the ones we needed in that
project so opted to fix them in Aries.
If we could get them fixed then that might be a solution.
Submit a patch! I can get them applied there easily enough. I’m
completely against having yet another bundle here when the other bundles
are the ones that will be be used by all the other projects.
Dan
- Ray
I really would prefer not getting into a situation where we have a bunch
of project that are commonly used together starting to pull in multiple
versions or implementations of the same bundles. For example: CXF uses
and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
which would obviously result in multiple bundles exporting the same
package/versions.
Dan
On Dec 21, 2017, at 9:28 AM, Raymond Auge <ra...@liferay.com><
mailto:raymond.auge@liferay.com>>
wrote:
Hi Tim,
I was thinking of proposing this very thing over the last few weeks.
I had already deliberately pushed the CDI related spec jars and also the
spec jar for JAX-RS into an aries sub-group in maven in order to better
accommodate and reflect this very thing.
So, I would be a big +1 for having these in a specific sub-project.
- Ray
On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org><
mailto:timothyjward@apache.org>>
wrote:
Hi all,
I’ve noticed that an increasing number of Aries projects are producing
wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
is a
good thing, as few other Open Source projects package the jars with OSGi
contract metadata.
I do wonder, however, if these spec jars should be provided by a
separate
Aries project, rather than scattered across multiple other projects. I
have
two main reasons for this.
1. It makes the code for packaging the spec jars harder to find in
source
control
2. It creates some non-obvious links between projects. It’s clear why
tx-control depends on JPA, but not why JAX-RS depends on CDI!
The spec jars are mostly being put into a separate Maven group already.
I
would simply see this as a formalisation of that earlier decision.
Thoughts?
Tim
Sent from my iPhone
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com<http:
//coders.talend.com/<http://coders.talend.com/>>
--
Daniel Kulp
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com<http://coders.talend.com/>
Re: Aries Spec Jars
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 22, 2017, at 10:30 AM, Raymond Auge <ra...@liferay.com> 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 <dkulp@apache.org<mailto:dkulp
>> @apache.org>> wrote:
>>>
>>>
>>>
>>> On Dec 21, 2017, at 1:00 PM, Raymond Auge <raymond.auge@liferay.com<
>> mailto:raymond.auge@liferay.com>> wrote:
>>>
>>> On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <dkulp@apache.org<mailto:
>> dkulp@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 of the original license of
>>> the specification artifacts they touch. They also violate the Apache
>>> guidelines for repackaging such artifacts.
>>>
>>> I personally didn't have the stomach to repair the ones we needed in that
>>> project so opted to fix them in Aries.
>>>
>>> If we could get them fixed then that might be a solution.
>>>
>>>
>>> Submit a patch! I can get them applied there easily enough. I’m
>> completely against having yet another bundle here when the other bundles
>> are the ones that will be be used by all the other projects.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>
>>>
>>> - Ray
>>>
>>>
>>>
>>> I really would prefer not getting into a situation where we have a bunch
>>> of project that are commonly used together starting to pull in multiple
>>> versions or implementations of the same bundles. For example: CXF uses
>>> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
>>> which would obviously result in multiple bundles exporting the same
>>> package/versions.
>>>
>>> Dan
>>>
>>>
>>>
>>> On Dec 21, 2017, at 9:28 AM, Raymond Auge <raymond.auge@liferay.com<
>> mailto:raymond.auge@liferay.com>>
>>> wrote:
>>>
>>> Hi Tim,
>>>
>>> I was thinking of proposing this very thing over the last few weeks.
>>>
>>> I had already deliberately pushed the CDI related spec jars and also the
>>> spec jar for JAX-RS into an aries sub-group in maven in order to better
>>> accommodate and reflect this very thing.
>>>
>>> So, I would be a big +1 for having these in a specific sub-project.
>>>
>>> - Ray
>>>
>>> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <timothyjward@apache.org<
>> mailto:timothyjward@apache.org>>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I’ve noticed that an increasing number of Aries projects are producing
>>> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
>>> is a
>>> good thing, as few other Open Source projects package the jars with OSGi
>>> contract metadata.
>>>
>>> I do wonder, however, if these spec jars should be provided by a
>>> separate
>>> Aries project, rather than scattered across multiple other projects. I
>>> have
>>> two main reasons for this.
>>>
>>> 1. It makes the code for packaging the spec jars harder to find in
>>> source
>>> control
>>>
>>> 2. It creates some non-obvious links between projects. It’s clear why
>>> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>>>
>>> The spec jars are mostly being put into a separate Maven group already.
>>> I
>>> would simply see this as a formalisation of that earlier decision.
>>>
>>> Thoughts?
>>>
>>> Tim
>>>
>>> Sent from my iPhone
>>>
>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>>> (@OSGiAlliance)
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>>
>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>>
>>> --
>>> Daniel Kulp
>>> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com<http:
>> //coders.talend.com/>
>>>
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Aries Spec Jars
Posted by Raymond Auge <ra...@liferay.com>.
On Fri, Dec 22, 2017 at 8:12 AM, Daniel Kulp <dk...@apache.org> wrote:
>
>
> > On Dec 22, 2017, at 4:14 AM, Timothy Ward <ti...@apache.org>
> wrote:
> >
> > I’m completely against having yet another bundle here when the other
> bundles are the ones that will be be used by all the other projects.
> >
> > Well we already do have working spec bundles here at Aries (and have had
> for quite some time), so is your proposal to remove them?
>
> 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.
From that perspective they are free to make implementation choices which is
totally fine for that case. However those choices are proprietary.
>
>
> > 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!
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.
>
> > As Ray points out the licensing also needs to be fixed before any of the
> bundles can be used in an OSGi reference implementation (which affects at
> least Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA).
> The reference implementations also need to be ready for the R7 release in
> the next month or so. My original suggestion was a simple movement of the
> existing bundles, do we have a different solution that’s workable in that
> time-frame?
>
> Let me be clear: I intent to vote -1 on any release that contains the api
> bundle as it currently stands in Aries, PARTICULARLY if there has been no
> attempt a all to fix any problems in the other locations.
>
> This particular situation is even worse… 95% (or more) of the testing of
> CXF/JAX-RS in OSGi is done using the ServiceMix spec bundles. I have
> little to no confidence in any other option at this point.
>
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.
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.
- Ray
>
> Dan
>
>
>
>
> >
> > Regards,
> >
> > Tim
> >
> > On 21 Dec 2017, at 18:16, Daniel Kulp <dkulp@apache.org<mailto:dkulp
> @apache.org>> wrote:
> >
> >
> >
> > On Dec 21, 2017, at 1:00 PM, Raymond Auge <raymond.auge@liferay.com<
> mailto:raymond.auge@liferay.com>> wrote:
> >
> > On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <dkulp@apache.org<mailto:
> dkulp@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 of the original license of
> > the specification artifacts they touch. They also violate the Apache
> > guidelines for repackaging such artifacts.
> >
> > I personally didn't have the stomach to repair the ones we needed in that
> > project so opted to fix them in Aries.
> >
> > If we could get them fixed then that might be a solution.
> >
> >
> > Submit a patch! I can get them applied there easily enough. I’m
> completely against having yet another bundle here when the other bundles
> are the ones that will be be used by all the other projects.
> >
> > Dan
> >
> >
> >
> >
> >
> >
> > - Ray
> >
> >
> >
> > I really would prefer not getting into a situation where we have a bunch
> > of project that are commonly used together starting to pull in multiple
> > versions or implementations of the same bundles. For example: CXF uses
> > and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
> > which would obviously result in multiple bundles exporting the same
> > package/versions.
> >
> > Dan
> >
> >
> >
> > On Dec 21, 2017, at 9:28 AM, Raymond Auge <raymond.auge@liferay.com<
> mailto:raymond.auge@liferay.com>>
> > wrote:
> >
> > Hi Tim,
> >
> > I was thinking of proposing this very thing over the last few weeks.
> >
> > I had already deliberately pushed the CDI related spec jars and also the
> > spec jar for JAX-RS into an aries sub-group in maven in order to better
> > accommodate and reflect this very thing.
> >
> > So, I would be a big +1 for having these in a specific sub-project.
> >
> > - Ray
> >
> > On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <timothyjward@apache.org<
> mailto:timothyjward@apache.org>>
> > wrote:
> >
> > Hi all,
> >
> > I’ve noticed that an increasing number of Aries projects are producing
> > wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
> > is a
> > good thing, as few other Open Source projects package the jars with OSGi
> > contract metadata.
> >
> > I do wonder, however, if these spec jars should be provided by a
> > separate
> > Aries project, rather than scattered across multiple other projects. I
> > have
> > two main reasons for this.
> >
> > 1. It makes the code for packaging the spec jars harder to find in
> > source
> > control
> >
> > 2. It creates some non-obvious links between projects. It’s clear why
> > tx-control depends on JPA, but not why JAX-RS depends on CDI!
> >
> > The spec jars are mostly being put into a separate Maven group already.
> > I
> > would simply see this as a formalisation of that earlier decision.
> >
> > Thoughts?
> >
> > Tim
> >
> > Sent from my iPhone
> >
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > (@OSGiAlliance)
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com
> >
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> > Talend Community Coder - http://coders.talend.com<http:
> //coders.talend.com/>
> >
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: Aries Spec Jars
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 22, 2017, at 4:14 AM, Timothy Ward <ti...@apache.org> wrote:
>
> I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects.
>
> Well we already do have working spec bundles here at Aries (and have had for quite some time), so is your proposal to remove them?
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.
> 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.
> As Ray points out the licensing also needs to be fixed before any of the bundles can be used in an OSGi reference implementation (which affects at least Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA). The reference implementations also need to be ready for the R7 release in the next month or so. My original suggestion was a simple movement of the existing bundles, do we have a different solution that’s workable in that time-frame?
Let me be clear: I intent to vote -1 on any release that contains the api bundle as it currently stands in Aries, PARTICULARLY if there has been no attempt a all to fix any problems in the other locations.
This particular situation is even worse… 95% (or more) of the testing of CXF/JAX-RS in OSGi is done using the ServiceMix spec bundles. I have little to no confidence in any other option at this point.
Dan
>
> Regards,
>
> Tim
>
> On 21 Dec 2017, at 18:16, Daniel Kulp <dk...@apache.org>> wrote:
>
>
>
> On Dec 21, 2017, at 1:00 PM, Raymond Auge <ra...@liferay.com>> wrote:
>
> On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <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 of the original license of
> the specification artifacts they touch. They also violate the Apache
> guidelines for repackaging such artifacts.
>
> I personally didn't have the stomach to repair the ones we needed in that
> project so opted to fix them in Aries.
>
> If we could get them fixed then that might be a solution.
>
>
> Submit a patch! I can get them applied there easily enough. I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects.
>
> Dan
>
>
>
>
>
>
> - Ray
>
>
>
> I really would prefer not getting into a situation where we have a bunch
> of project that are commonly used together starting to pull in multiple
> versions or implementations of the same bundles. For example: CXF uses
> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
> which would obviously result in multiple bundles exporting the same
> package/versions.
>
> Dan
>
>
>
> On Dec 21, 2017, at 9:28 AM, Raymond Auge <ra...@liferay.com>>
> wrote:
>
> Hi Tim,
>
> I was thinking of proposing this very thing over the last few weeks.
>
> I had already deliberately pushed the CDI related spec jars and also the
> spec jar for JAX-RS into an aries sub-group in maven in order to better
> accommodate and reflect this very thing.
>
> So, I would be a big +1 for having these in a specific sub-project.
>
> - Ray
>
> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>>
> wrote:
>
> Hi all,
>
> I’ve noticed that an increasing number of Aries projects are producing
> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
> is a
> good thing, as few other Open Source projects package the jars with OSGi
> contract metadata.
>
> I do wonder, however, if these spec jars should be provided by a
> separate
> Aries project, rather than scattered across multiple other projects. I
> have
> two main reasons for this.
>
> 1. It makes the code for packaging the spec jars harder to find in
> source
> control
>
> 2. It creates some non-obvious links between projects. It’s clear why
> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>
> The spec jars are mostly being put into a separate Maven group already.
> I
> would simply see this as a formalisation of that earlier decision.
>
> Thoughts?
>
> Tim
>
> Sent from my iPhone
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
> --
> Daniel Kulp
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
>
> --
> Daniel Kulp
> dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com<http://coders.talend.com/>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Aries Spec Jars
Posted by Timothy Ward <ti...@apache.org>.
I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects.
Well we already do have working spec bundles here at Aries (and have had for quite some time), so is your proposal to remove them?
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?
As Ray points out the licensing also needs to be fixed before any of the bundles can be used in an OSGi reference implementation (which affects at least Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA). The reference implementations also need to be ready for the R7 release in the next month or so. My original suggestion was a simple movement of the existing bundles, do we have a different solution that’s workable in that time-frame?
Regards,
Tim
On 21 Dec 2017, at 18:16, Daniel Kulp <dk...@apache.org>> wrote:
On Dec 21, 2017, at 1:00 PM, Raymond Auge <ra...@liferay.com>> wrote:
On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <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 of the original license of
the specification artifacts they touch. They also violate the Apache
guidelines for repackaging such artifacts.
I personally didn't have the stomach to repair the ones we needed in that
project so opted to fix them in Aries.
If we could get them fixed then that might be a solution.
Submit a patch! I can get them applied there easily enough. I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects.
Dan
- Ray
I really would prefer not getting into a situation where we have a bunch
of project that are commonly used together starting to pull in multiple
versions or implementations of the same bundles. For example: CXF uses
and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
which would obviously result in multiple bundles exporting the same
package/versions.
Dan
On Dec 21, 2017, at 9:28 AM, Raymond Auge <ra...@liferay.com>>
wrote:
Hi Tim,
I was thinking of proposing this very thing over the last few weeks.
I had already deliberately pushed the CDI related spec jars and also the
spec jar for JAX-RS into an aries sub-group in maven in order to better
accommodate and reflect this very thing.
So, I would be a big +1 for having these in a specific sub-project.
- Ray
On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>>
wrote:
Hi all,
I’ve noticed that an increasing number of Aries projects are producing
wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
is a
good thing, as few other Open Source projects package the jars with OSGi
contract metadata.
I do wonder, however, if these spec jars should be provided by a
separate
Aries project, rather than scattered across multiple other projects. I
have
two main reasons for this.
1. It makes the code for packaging the spec jars harder to find in
source
control
2. It creates some non-obvious links between projects. It’s clear why
tx-control depends on JPA, but not why JAX-RS depends on CDI!
The spec jars are mostly being put into a separate Maven group already.
I
would simply see this as a formalisation of that earlier decision.
Thoughts?
Tim
Sent from my iPhone
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org<ma...@apache.org> - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com<http://coders.talend.com/>
Re: Aries Spec Jars
Posted by Daniel Kulp <dk...@apache.org>.
> On Dec 21, 2017, at 1:00 PM, Raymond Auge <ra...@liferay.com> wrote:
>
> On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <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 of the original license of
> the specification artifacts they touch. They also violate the Apache
> guidelines for repackaging such artifacts.
>
> I personally didn't have the stomach to repair the ones we needed in that
> project so opted to fix them in Aries.
>
> If we could get them fixed then that might be a solution.
Submit a patch! I can get them applied there easily enough. I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects.
Dan
>
> - Ray
>
>
>>
>> I really would prefer not getting into a situation where we have a bunch
>> of project that are commonly used together starting to pull in multiple
>> versions or implementations of the same bundles. For example: CXF uses
>> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
>> which would obviously result in multiple bundles exporting the same
>> package/versions.
>>
>> Dan
>>
>>
>>
>>> On Dec 21, 2017, at 9:28 AM, Raymond Auge <ra...@liferay.com>
>> wrote:
>>>
>>> Hi Tim,
>>>
>>> I was thinking of proposing this very thing over the last few weeks.
>>>
>>> I had already deliberately pushed the CDI related spec jars and also the
>>> spec jar for JAX-RS into an aries sub-group in maven in order to better
>>> accommodate and reflect this very thing.
>>>
>>> So, I would be a big +1 for having these in a specific sub-project.
>>>
>>> - Ray
>>>
>>> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I’ve noticed that an increasing number of Aries projects are producing
>>>> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
>> is a
>>>> good thing, as few other Open Source projects package the jars with OSGi
>>>> contract metadata.
>>>>
>>>> I do wonder, however, if these spec jars should be provided by a
>> separate
>>>> Aries project, rather than scattered across multiple other projects. I
>> have
>>>> two main reasons for this.
>>>>
>>>> 1. It makes the code for packaging the spec jars harder to find in
>> source
>>>> control
>>>>
>>>> 2. It creates some non-obvious links between projects. It’s clear why
>>>> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>>>>
>>>> The spec jars are mostly being put into a separate Maven group already.
>> I
>>>> would simply see this as a formalisation of that earlier decision.
>>>>
>>>> Thoughts?
>>>>
>>>> Tim
>>>>
>>>> Sent from my iPhone
>>>
>>>
>>>
>>>
>>> --
>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
>>> (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
>>> (@Liferay)
>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
>> (@OSGiAlliance)
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org - http://dankulp.com/blog
>> Talend Community Coder - http://coders.talend.com
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Aries Spec Jars
Posted by Raymond Auge <ra...@liferay.com>.
RE: geronimo
The geronimo ones were good in large part, but they aren't complete and
often no up to date and we couldn't afford to wait for someone to clean
room the updates we needed.
On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <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 of the original license of
the specification artifacts they touch. They also violate the Apache
guidelines for repackaging such artifacts.
I personally didn't have the stomach to repair the ones we needed in that
project so opted to fix them in Aries.
If we could get them fixed then that might be a solution.
- Ray
>
> I really would prefer not getting into a situation where we have a bunch
> of project that are commonly used together starting to pull in multiple
> versions or implementations of the same bundles. For example: CXF uses
> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle
> which would obviously result in multiple bundles exporting the same
> package/versions.
>
> Dan
>
>
>
> > On Dec 21, 2017, at 9:28 AM, Raymond Auge <ra...@liferay.com>
> wrote:
> >
> > Hi Tim,
> >
> > I was thinking of proposing this very thing over the last few weeks.
> >
> > I had already deliberately pushed the CDI related spec jars and also the
> > spec jar for JAX-RS into an aries sub-group in maven in order to better
> > accommodate and reflect this very thing.
> >
> > So, I would be a big +1 for having these in a specific sub-project.
> >
> > - Ray
> >
> > On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>
> > wrote:
> >
> >> Hi all,
> >>
> >> I’ve noticed that an increasing number of Aries projects are producing
> >> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this
> is a
> >> good thing, as few other Open Source projects package the jars with OSGi
> >> contract metadata.
> >>
> >> I do wonder, however, if these spec jars should be provided by a
> separate
> >> Aries project, rather than scattered across multiple other projects. I
> have
> >> two main reasons for this.
> >>
> >> 1. It makes the code for packaging the spec jars harder to find in
> source
> >> control
> >>
> >> 2. It creates some non-obvious links between projects. It’s clear why
> >> tx-control depends on JPA, but not why JAX-RS depends on CDI!
> >>
> >> The spec jars are mostly being put into a separate Maven group already.
> I
> >> would simply see this as a formalisation of that earlier decision.
> >>
> >> Thoughts?
> >>
> >> Tim
> >>
> >> Sent from my iPhone
> >
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: Aries Spec Jars
Posted by Daniel Kulp <dk...@apache.org>.
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?
I really would prefer not getting into a situation where we have a bunch of project that are commonly used together starting to pull in multiple versions or implementations of the same bundles. For example: CXF uses and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle which would obviously result in multiple bundles exporting the same package/versions.
Dan
> On Dec 21, 2017, at 9:28 AM, Raymond Auge <ra...@liferay.com> wrote:
>
> Hi Tim,
>
> I was thinking of proposing this very thing over the last few weeks.
>
> I had already deliberately pushed the CDI related spec jars and also the
> spec jar for JAX-RS into an aries sub-group in maven in order to better
> accommodate and reflect this very thing.
>
> So, I would be a big +1 for having these in a specific sub-project.
>
> - Ray
>
> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>
> wrote:
>
>> Hi all,
>>
>> I’ve noticed that an increasing number of Aries projects are producing
>> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this is a
>> good thing, as few other Open Source projects package the jars with OSGi
>> contract metadata.
>>
>> I do wonder, however, if these spec jars should be provided by a separate
>> Aries project, rather than scattered across multiple other projects. I have
>> two main reasons for this.
>>
>> 1. It makes the code for packaging the spec jars harder to find in source
>> control
>>
>> 2. It creates some non-obvious links between projects. It’s clear why
>> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>>
>> The spec jars are mostly being put into a separate Maven group already. I
>> would simply see this as a formalisation of that earlier decision.
>>
>> Thoughts?
>>
>> Tim
>>
>> Sent from my iPhone
>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Aries Spec Jars
Posted by Raymond Auge <ra...@liferay.com>.
Hi Tim,
I was thinking of proposing this very thing over the last few weeks.
I had already deliberately pushed the CDI related spec jars and also the
spec jar for JAX-RS into an aries sub-group in maven in order to better
accommodate and reflect this very thing.
So, I would be a big +1 for having these in a specific sub-project.
- Ray
On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <ti...@apache.org>
wrote:
> Hi all,
>
> I’ve noticed that an increasing number of Aries projects are producing
> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this is a
> good thing, as few other Open Source projects package the jars with OSGi
> contract metadata.
>
> I do wonder, however, if these spec jars should be provided by a separate
> Aries project, rather than scattered across multiple other projects. I have
> two main reasons for this.
>
> 1. It makes the code for packaging the spec jars harder to find in source
> control
>
> 2. It creates some non-obvious links between projects. It’s clear why
> tx-control depends on JPA, but not why JAX-RS depends on CDI!
>
> The spec jars are mostly being put into a separate Maven group already. I
> would simply see this as a formalisation of that earlier decision.
>
> Thoughts?
>
> Tim
>
> Sent from my iPhone
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)