> The answer to your scenario is that in cases
where there is no
> natural dependency between a facet and a runtime and you want to
> declare an extension that references both you put that extension in
> some other plugin that takes a dependency on the plugin that defines
> the facet in question and the plugin that defines the runtime in
> question. This a pretty natural dependency management and something
> that you would have to do regardless if you wanted to do something
> more than a purely declarative extension. I understand that there
> are cases where this is mighty inconvenient, which is why we have
> enhancement requests like the following that would allow one to
> fudge the dependencies by telling the framework of cases where
> problems are ok to ignore.
I had thought of that. Unfortunately,
"mighty inconvenient" is accurate - it would mean at least 7
new plugins in WTP alone, with nothing more than a short plugin.xml in
each. :( We'd need to figure out how to setup the dependencies so that
these plugins are only in p2 install scenarios when both JSDT and each
particular server adapter are installed. And finally the installable servers
on remote update sites would need to do the same.
Yup, an "optional" flag or
some an equivalent way for an extender to tell the framework that it's
ok if missing would be great.
> > So this error may only indicate that the
user's install doesn't
> include JSDT or some > > other facet, and not an actual problem.
Until we can fix facets to
> only report real > > problems, we should really be removing this
error to stop
> cluttering user .logs unnecessarily. > > Determining whether a missing facet is a problem
or not is a case-
> by-case exercise. The framework cannot make that determination for
> you nor can this be generalized at the level of the entire extension
> point. [...]
> However, there are plenty of cases where a failure of defaultFacets
> contribution will create a situation where the project wizard with
> be put into an invalid state by default. [...]
I completely agree that there are potential
error situations, and that the framework can't tell the difference between
the two here. The part I don't like is that there's no way for me to tell
or help the framework, and it logs an error even if there is nothing wrong.
> > Until we can fix facets to only report real
problems, we should
> really be removing > > this error to stop cluttering user .logs
unnecessarily. > > I still havenât heard a compelling argument
for why we should
> cripple the error reporting that is far more likely than not to be
> flagging a real problem so that we can paper over an issue that will
> be resolved via other means anyway.
Resolving the bug above is a far better
solution. If we're not going to fix that soon, I've just seen facets "cry
wolf" enough that I start to ignore errors from it. If we can't actually
tell if there is an error, I still think we should either indicate that
in the message and status code, or not log at all.