aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Aries Spec Jars
Date Fri, 22 Dec 2017 13:12:25 GMT


> On Dec 22, 2017, at 4:14 AM, Timothy Ward <timothyjward@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 <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<mailto: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<mailto:dkulp@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


Mime
View raw message