felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Handling of provisional OSGi API?
Date Fri, 16 May 2014 21:49:40 GMT
+1

2014-05-16 23:24 GMT+02:00 Richard S. Hall <heavy@ungoverned.org>:

> 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
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message