Good question. I guess I had something in mind where you can globally configure certain analyser reported issues to be remapped. In other words, somewhat similar to what we have but not just all errors into warnings but maybe something smarter - I can't say I did think it through completely yet :-)
regards, Karl On Wed, Dec 18, 2019 at 11:53 AM Carsten Ziegeler <[email protected]> wrote: > > For now we have a global config which can turn every warning into an > error; then analysers can have a separate config. > > The question is where you want to maintain such a setting. In the > feature file where the configuration is and tell the analyser to ignore > it? Or everywhere the feature model is analysed? > > Regards > Carsten > > On 18.12.2019 11:31, Karl Pauls wrote: > > I wouldn't make them errors but warnings - while maybe not > > recommended, there certainly are cases out there where metatype > > definitions are not containing all options to protect the innocent. > > > > That said, maybe we should consider making the analyser configurable > > as to what is considered an error vs. a warning? > > > > regards, > > > > Karl > > > > On Wed, Dec 18, 2019 at 11:20 AM Robert Munteanu <[email protected]> wrote: > >> > >> Right, we will probably miss some metatype defintions, and I guess > >> that's ok. > >> > >> I would start with only looking at the metatype definitions included in > >> the bundles, and then trying to match them to the configurations > >> defined in the file. > >> > >> The safe things to report (as errors?) would be configuration > >> properties that: > >> > >> 1. Are defined for a component with a metatype > >> 2. Do not match the list of properties defined in the metatype > >> > >> How does that sound? > >> > >> Robert > >> > >> On Tue, 2019-12-17 at 10:50 +0100, Carsten Ziegeler wrote: > >>> Makes definitely sense, the big question is where you get the > >>> metadata > >>> from. In the easiest case you have a bundle in your feature which > >>> contains the metadata XML files. But such a bundle could also > >>> "manually" > >>> create the metadata at runtime using the metadata API (we have some > >>> cases like the Apache Felix Jetty implementation for example). > >>> But you also might have a configuration where there is no bundle > >>> declaring the metadata in any way in your feature; either because > >>> there > >>> is no metadata (lazy developer) or it is declared in another feature > >>> (ok, this might be a rare use case and we can probably ignore it) > >>> > >>> Regards > >>> Carsten > >>> > >>> On 16.12.2019 15:56, David Bosschaert wrote: > >>>> Hi Robert, > >>>> > >>>> That sounds like a very nice addition. I think it could be an > >>>> additional > >>>> Feature Model analyser, that runs as part of the set of analysers. > >>>> I don't think it was considered before, could you please file an > >>>> issue for > >>>> it? > >>>> > >>>> Best regards, > >>>> > >>>> David > >>>> > >>>> On Mon, 16 Dec 2019 at 13:28, Robert Munteanu <[email protected]> > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> Being a sloppy typist, I often get the configuration values wrong > >>>>> in > >>>>> feature model files. I am thinking that validating the > >>>>> configuration > >>>>> values defined in a feature model file against the metatype > >>>>> definition > >>>>> of the matching components would help a lot. > >>>>> > >>>>> Is there something like this planned? If not, would it make sense > >>>>> to > >>>>> add it to the roadmap? > >>>>> > >>>>> Thanks, > >>>>> Robert > >>>>> > >>>>> > >> > > > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] -- Karl Pauls [email protected]
