+1
Regards
JB
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 <[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]
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
