felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Handling of provisional OSGi API?
Date Sat, 17 May 2014 05:09:33 GMT


On 05/16/2014 11:24 PM, Richard S. Hall wrote:
> There was thought that went into that policy, it wasn't just pulled out
> of the air...further, from experience of working on that specs that
> didn't make the cut (original OBR and Gogo), I can say the policy does a
> good job of avoiding the confusion/complication created in those cases.
> So, working around the policy based on personal whim, doesn't seem like
> a good idea...that sort of makes it not a policy.
> However, all policies can be improved. You could argue that the policy
> should simply be modified, as David suggests, to say only "released"
> subprojects must not contain provisional API.
> I'd personally be fine with that, but such a subproject would still have
> to be fine with not having an official release until the specs are final.
> -> richard
> On 5/16/14, 13:59 , David Jencks wrote:
>> Well, I pretty much disagree with the existing policy being good or
>> nice, but I think I agree with your proposal.
>> I think that there should be very different policy for the svn tree
>> and for releases.  I don't think it's a very good idea to have a
>> release with a provisional osgi api, whether or not it's had its
>> packages shaded.  However if we decide we need to do this I think
>> _either_ renaming the packages _or_ marking the packages provisional
>> should be sufficient, not both.
>> For the svn tree, I think it's fine to just copy the osgi draft source
>> into some appropriate location and build it as part of the project.
>> The svn tree is not for general consumption, if you use it you are
>> supposed to know what you are doing and you certainly aren't supposed
>> to rely on it for production without doing your own deternimation that
>> it is entirely suitable, since it comes with no assurances of anything
>> from apache.  We just shouldn't release anything in this state: either
>> the spec gets released first, or we mark the spec packages provisional
>> or rename them.
>> I have the same problem with  the felix ds/rfc 190 work, with the new
>> runtime and dto packages, and realistically for me the options are
>> either changing the policy, or keeping my work visible on github until
>> the spec is released.
>> I don't have time or interest to investigate, but it might be possible
>> to use the maven shade plugin to rename the packages in byte code.  I
>> imagine we'd have to run bnd after this step.  I don't know if the
>> shading can be done to integration tests as well so the instructions
>> to bnd don't have to be duplicated with and without the mangled
>> package names so we can create an unshaded bundle for unshaded
>> integration tests.
>> thanks for reminding me to think about this before I committed :-)
>> david jencks
>> On May 15, 2014, at 11:14 PM, Carsten Ziegeler <cziegeler@apache.org>
>> wrote:
>>> Hi,
>>> right now we have a policy for handling provisional OSGi API (API
>>> that is
>>> currently drafted in the OSGi expert groups but not final or officially
>>> released yet):
>>> http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
>>> While the policy is good and nice, it requires to rename the packages
>>> from
>>> an OSGi namespace to an Apache one for the reasons stated in the policy.
>>> However, this creates a burden for people using this stuff, e.g. when
>>> writing tests as these need to be refactored later on anyway.
>>> The reference implementation of the new Http Service (RFC 189) will
>>> be done
>>> as part of Apache Felix and we would like to start working on this in
>>> the
>>> open. Therefore we need to commit the current version of the API draft
>>> somewhere. I think if we do this in the whiteboard section, it should be
>>> clear enough that the API is provisional and we don't need to rename the
>>> packages. We can also add all kinds of disclaimers/readmes etc.
>>> But before doing so, I would like to get the general feeling about this.
>>> So, wdyt?
>>> Thanks
>>> Carsten
>>> --
>>> Carsten Ziegeler
>>> cziegeler@apache.org

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message