Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] JSDT facet gone missing in 3.0.4?

With regards to a project referencing a missing facet, I agree that's an error and should be noted. With a *server* "supporting" a missing facet, I can't see this as an error ever.

A server that can deploy 100 facet types / module types doesn't "require" *ANY* of them in the installation. Unless I'm completely mistaken. I personally can't imagine a situation where a server type *requires* a facet type to be installed to function properly.

Maybe I'm wrong and simply misunderstand, or suffer from a lack of imagination (both of which are possible). If someone can provide me a basic example of a server type actually requiring, being unable to function without, a specific facet type be installed in order to function, I would very much like to hear it.

- Rob Stryker

Tim deBoer wrote:

Hi Konstantin,

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

> defaultFacets extension point should support optional contributions
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=251722

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.

Thanks,
Tim deBoer
deboer@xxxxxxxxxx
------------------------------------------------------------------------

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev



Back to the top