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 <[email protected]> > 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 <[email protected]> > 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 > > [email protected] > > -- Carsten Ziegeler [email protected]
