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 Thu, 21 Dec 2017 17:43:43 GMT
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 <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>
> 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


Mime
View raw message