Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: domain of justinedelson@gmail.com
 designates 209.85.214.175 as permitted sender)
MIME-Version: 1.0
Sender: justinedelson@gmail.com
In-Reply-To: 
 <CAKkCf4qqKOLewLCAr_yS_fWesZSuCWyxzhQn6JUkT7RRYZj-YA@mail.gmail.com>
References: 
 <CAKkCf4qqKOLewLCAr_yS_fWesZSuCWyxzhQn6JUkT7RRYZj-YA@mail.gmail.com>
Date: Mon, 10 Jun 2013 17:52:24 -0400
Message-ID: 
 <CAOAO1Sh+ONuY0wLNGn40vEHkKW+q_oF61_a+hLkVGBWn5EyExw@mail.gmail.com>
Subject: Re: [SCR Tooling] Discontinuing support for some features
From: Justin Edelson <justin@justinedelson.com>
To: "dev@felix.apache.org" <dev@felix.apache.org>
Content-Type: multipart/alternative; boundary=089e0112ce20bace4e04ded3cbcf

--089e0112ce20bace4e04ded3cbcf
Content-Type: text/plain; charset=ISO-8859-1

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

--089e0112ce20bace4e04ded3cbcf--