felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [SCR Tooling] Discontinuing support for some features
Date Mon, 10 Jun 2013 21:44:32 GMT
Inheritance can break if a lifecycle or reference method is found at build
time in the super class which is not available at run time, e.g. like the
activate method or a bind one.
Right, as the super class needs to be exported, it should be semantically
versioned as well - however such methods might not be considered for
versioning (although they should)

Carsten


2013/6/10 David Jencks <david_jencks@yahoo.com>

> 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
>
>


-- 
Carsten Ziegeler
cziegeler@apache.org

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