On 5/16/14, 20:43 , David Jencks wrote:
You have a point about specs that don't get released. And in such a
circumstance having something released with org.osgi packages marked
provisional would be sort of a disaster.
But if a felix subproject is going to be an osgi ri, it really needs to be
developed with the right package names. Otherwise, for instance, debugging the
conformance test suite will be more or less impossible, as well as making
running the ri against the ct implausible.
I believe we did have this issue with the Config Admin RI and somehow we
managed.
So I think I'd like the policy to say (sub) projects are strongly discouraged
from releasing anything with a non released osgi spec api no matter what
package it's moved to and how provisional it's marked, but it's ok to have
unreleased org.osgi packages in source as long as either the spec gets released
before any felix release is made or they are removed before any felix release
is made.
I don't think we can leave policy as a recommendation, because then it
still leaves it up to whomever to decide.
Again, I don't have an issue with saying it is okay in source form, but
not in a released artifact.
My next DS commits add the DTO stuff, so unless the policy is changed they will
have to wait on github for a while.
So, make a modified policy proposal and put it up for comments and
ultimately a vote.
-> richard
thanks
david jencks
On May 16, 2014, at 2:24 PM, Richard S. Hall <he...@ungoverned.org> 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 <cziege...@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
cziege...@apache.org
