[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [wtp-dev] JSDT facet gone missing in 3.0.4?
- From: Rob Stryker <rob.stryker@xxxxxxxxxx>
- Date: Fri, 06 Feb 2009 15:08:50 +0800
- Delivered-to: email@example.com
- User-agent: Thunderbird 220.127.116.11 (X11/20080501)
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:
> 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
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.
wtp-dev mailing list