> On Dec 22, 2017, at 4:14 AM, Timothy Ward <[email protected]> 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 > <[email protected]<mailto:[email protected]>> wrote: > > > > On Dec 21, 2017, at 1:00 PM, Raymond Auge > <[email protected]<mailto:[email protected]>> wrote: > > On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp > <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> > 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 > <[email protected]<mailto:[email protected]>> > 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 > [email protected]<mailto:[email protected]> - 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 > [email protected]<mailto:[email protected]> - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com<http://coders.talend.com/> > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
