+1 2014-05-16 23:24 GMT+02:00 Richard S. Hall <[email protected]>:
> 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 <[email protected]> >> 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 >>> [email protected] >>> >> >
