You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Carsten Ziegeler <cz...@apache.org> on 2013/06/10 19:21:02 UTC
[SCR Tooling] Discontinuing support for some features
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
Re: [SCR Tooling] Discontinuing support for some features
Posted by Justin Edelson <ju...@justinedelson.com>.
+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.
Justin
On Mon, Jun 10, 2013 at 1:21 PM, Carsten Ziegeler <cz...@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
>
Re: [SCR Tooling] Discontinuing support for some features
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <da...@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 <cz...@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
Re: [SCR Tooling] Discontinuing support for some features
Posted by David Jencks <da...@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 <cz...@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
Re: [SCR Tooling] Discontinuing support for some features
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 10.06.2013 um 19:21 schrieb Carsten Ziegeler:
> 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.
+1
>
> 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.
+1
Regards
Felix
>
> WDYT?
>
> Regards
> Carsten
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: [SCR Tooling] Discontinuing support for some features
Posted by Carsten Ziegeler <cz...@apache.org>.
2013/6/11 Felix Meschberger <fm...@adobe.com>
> Actually versioning is not the only problem: The other problem is that for
> inheritance to work across bundle boundaries, the (abstract) base class has
> to be exported which is less of a problem if the base class is abstract
> (yet there might be arguments against exporting abstract classes, too).
>
> In any case, annotation inheritance creates strong coupling between
> bundles, which is what we don't want.
>
> While I totally agree that such a coupling should be avoided and
cross-bundle intheritance should rarely be used, having inheritance support
for annotations doesn't make it worse - you already have the class
inheritance which creates the tight coupling. So even if the annotations
don't support inheritance, you end up in the same situation.
But as said, we should drop that.
Carsten
> Regards
> Felix
>
>
> >
> > 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
Re: [SCR Tooling] Discontinuing support for some features
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 10.06.2013 um 19:21 schrieb Carsten Ziegeler:
> 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.
Actually versioning is not the only problem: The other problem is that for inheritance to work across bundle boundaries, the (abstract) base class has to be exported which is less of a problem if the base class is abstract (yet there might be arguments against exporting abstract classes, too).
In any case, annotation inheritance creates strong coupling between bundles, which is what we don't want.
Regards
Felix
>
> 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