felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <jus...@justinedelson.com>
Subject Re: [SCR Tooling] Discontinuing support for some features
Date Mon, 10 Jun 2013 21:52:24 GMT
+1 to both changes.

If it was possible to have inheritance work but ONLY within the same bundle
(and fail loudly if you tried to have inheritance across bundles), I think
that would be worth keeping, but not if it is too much trouble.


On Mon, Jun 10, 2013 at 1:21 PM, 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.
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org

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