felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [SCR Tooling] Discontinuing support for some features
Date Mon, 10 Jun 2013 21:00:17 GMT
While I kinda think everyone should use the bnd scr plugin and the DS annotations….. the
bnd plugin does support inheritance and IMO it is extremely useful even if you can break it
if you try hard enough.  I'm actually not sure how you'd break it if the bundle with the super
class was semantically versioned.  Maybe I'm not sure what "break" means.  Since this is compile
time annotation processing you'll get the result you compile with not what you run with, which
seems kinda like what you'd expect.

I don't see a lot of value in the one-large-xml-file.

thanks
david  jencks

On Jun 10, 2013, at 10:21 AM, Carsten Ziegeler <cziegeler@apache.org> wrote:

> Hi,
> 
> the current version of the scr tooling (maven scr plugin, ant task) has
> grown over time. We already had a major refactoring due to the drop of
> support the javadoc tags.
> 
> Now, looking at the code and the features, I would like to discuss to drop
> some more and create a new 2.0 release:
> 
> a) Current we support inheritance between components, this allows to
> inherit properties, references etc. from a super class or interface. While
> this sounds nice, the problem is that the base class might be different at
> runtime than at build time. So the only situation where inhertiance works
> reliable is by inheriting properties from an interface (due to semantic
> versioning) or if the base class is in the same bundle. However the latter
> can't be ensured by the SCR tooling as at the point the scr tools run, the
> final artifact has not been build yet.
> The DS annoations from the spec don't allow inheritance for this reason. So
> I think we can think about dropping thsi.
> 
> b) In order to support incremental builds we switched some time ago from
> generating a single large descriptor to separate descriptor files. This is
> now the default. I'm wondering whether we need the support for a single
> large xml descriptor file at all. If we drop this feature we could clean up
> a lot of code which is currently related to distinguishing between the two
> modes.
> 
> WDYT?
> 
> Regards
> Carsten
> 
> -- 
> Carsten Ziegeler
> cziegeler@apache.org


Mime
View raw message