>
Migration/deprecation is also a good topic, and (if it's not already documented
>
somewhere) I think the facet framework is on the hook to prove that it can be
safely
>
done between releases.
I agree that built-in deprecation and migration support is a
good area for the framework to extend the support to. If anyone has any
specific ideas or requirements, please open enhancement requests with details. There
is one such ER already that covers one specific case:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=255038
Of course, it would be particularly nice if people didn’t
just throw out broad requirements but actually contributed to the solution. ;)
>
The plugin that's defining the JSDT facet isn't going to list every server that
>
supports it because that's backwards and it has no idea what servers may be
>
provided by third-party adopters
Clearly.
Note that at least in the case of this specific JSDT issue, it’s not the
facet/runtime support mapping that’s at issue here, but rather the defaultFacets
extension point. The JSDT facet is marked as supported by all runtimes.
>
Server adapters can't say that they support an optional facet like JSDT either,
because
>
if they are ever installed without JSDT then the user will get these same
"errors" in their
>
log. I'm not aware of any feasible way to work around this with the current
facet framework,
>
and we need to fix this.
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.
defaultFacets
extension point should support optional contributions
https://bugs.eclipse.org/bugs/show_bug.cgi?id=251722
>
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. Even for the defaultFacets extension
point, we happen to know that the reason JSDT facet was added to the
defaultFacets for these adapters was a promotional exercise to get more
eyeballs on a new WTP feature, so we have people arguing that this case should
have been ignored. No real harm if the extension doesn’t take effect. 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. Say there is another facet that’s contributed that depends on
it and that happens to be found. Very bad problem that you want to be able to
quickly diagnose the root cause of.
>
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.
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf
Of Tim deBoer
Sent: Wednesday, February 04, 2009 1:50 PM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] JSDT facet gone missing in 3.0.4?
I totally agree
that we shouldn't remove facets in the service stream, and that's the first
issue to solve here. Migration/deprecation is also a good topic, and (if it's
not already documented somewhere) I think the facet framework is on the hook to
prove that it can be safely done between releases.
However, Rob
has a valid point here and this is *not* just "shoot the messenger".
The plugin that's defining the JSDT facet isn't going to list every server that
supports it because that's backwards and it has no idea what servers may be
provided by third-party adopters. Server adapters can't say that they support
an optional facet like JSDT either, because if they are ever installed without
JSDT then the user will get these same "errors" in their log. I'm not
aware of any feasible way to work around this with the current facet framework,
and we need to fix this.
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.
Thanks,
Tim deBoer
deboer@xxxxxxxxxx
|
From:
|
"Konstantin
Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>
|
|
To:
|
"'General
discussion of project-wide or architectural issues.'"
<wtp-dev@xxxxxxxxxxx>
|
|
Date:
|
02/04/2009
12:07 PM
|
|
Subject:
|
RE:
[wtp-dev] JSDT facet gone missing in 3.0.4?
|
I am somewhat tickled by this shoot the
messenger mentality. The framework
is telling us that there is a bug in the code and it is telling us where it
is located so that it can be more easily fixed. I honestly do not see how
it
would be better to not have known about this problem and shipped 3.0.4 with
a dozen broken extensions referring to a facet that no longer exist.
Regarding moving these messages to the Eclipse trace facility, I would
consider that as a misuse of the facility. The error log is for reporting
problems that plugins run into at runtime, which this case belongs to. The
trace facility is for providing additional verbose output so that one can
better understand operation of code under certain conditions. The Faceted
Project Framework uses both facilities where appropriate.
In all this noise, one important point from my original message has been
overlooked. Far more serious than the error messages in the log is that
there are now users out there with JSDT facet referenced in their project
metadata. Since the JSDT facet was added to the default facets sets for all
server adapters that are part of WTP, I would venture to guess that the
install base is quite considerable. When such users upgrade to 3.0.4, they
are going to end up with problem markers on their projects. Even if the
decision is made that architecturally the JSDT facet is not necessary, the
cat is out of the bag. The only reasonable course of action is to reinstate
the facet for 3.0.4 and figure out how to more gracefully phase it out in
3.1.
Rather than wasting time debating how problems should be reported, lets
concentrate on fixing the actual problem so that we can have a solid 3.0.4
release candidate for adopters to test. So far adopting 3.0.4 has been
rather rough for Oracle products. This is not the only issue we are
hitting.
More information to come as we test the build more thoroughly.
- Konstantin
-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Rob Stryker
Sent: Wednesday, February 04, 2009 5:27 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] JSDT facet gone missing in 3.0.4?
The usecase cited by Konstantin as a reason *not* to remove the logging is:
> " but the framework can't tell this case from a typo."
If the "typo" case is the only one cited, then the log message is
primarily to be used for debugging during development. In this case I
believe this should be trace level permanently,
I don't believe "optional" should even be considered, as in all
honesty
if a server supports 100 facets, each and every facet is optional.
The
server adopter can survive with or without jst.web modules in the
installation, with or without jst.ear modules in the installation, and
with or without my.custom.deploytype in the installation. How can we be
sure it can survive? Because if that facet isn't installed, then that
server adapter will never be asked to deploy it.
Max Rydahl Andersen wrote:
>
>>> In any case, what is 3.0.4 adopters supposed to do with this
bug ?
>>> Is there anything we can do to fix it ?
>>> We got a release coming up in March and would like to use
3.0.4 but
>>> want to be sure we don't flood users logs
>>> with these messages.
>> Looking at this again - then if the only thing the facet framework
is
>> doing is logging that there is a missing thing which does not
affect
>> any behavior at all shouldn't this be traced instead of error'd ?
>> I still find it really bad JSDT didn't fix this fully, but if the
fix
>> would be to lower the logging severity isn't that a better fix ?
> For reference https://bugs.eclipse.org/bugs/show_bug.cgi?id=251722 is
> the bug we initially raised this issue in.
> Reducing the logging really sounds to me like the least invasive fix -
> and when the framework once will allow for true optionality *then*
> hard-error'ing about it would be ok.
>
> Any other suggestions ?
>
> /max
>>
>> /max
>>>
>>> /max
>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Rob Stryker [mailto:rob.stryker@xxxxxxxxxx] Sent: Tuesday,
>>>>> February 03, 2009 8:49 PM
>>>>> To: konstantin.komissarchik@xxxxxxxxxx; General
discussion of
>>>>> project-wide or architectural issues.
>>>>> Subject: Re: [wtp-dev] JSDT facet gone missing in
3.0.4?
>>>>>
>>>>> Maybe this is just crazy talk, but perhaps a server or
runtime type
>>>>> expressing "support" for a facet type should
not cause error messages
>>>>> like this if the facet type is missing. I know, I
know... I'm
>>>>> living in
>>>>> a dream land... but in my thick empty skull I kinda
have this notion
>>>>> that "supporting" a facet isn't the same as
requiring it.
>>>>>
>>>>> But, I mean, I could be wrong. Maybe there's something
in the China
>>>>> water messing with my head. Crazy talk. ... Crazy.
>>>>>
>>>>> ;)
>>>>>
>>>>> - Rob Stryker
>>>>>
>>>>> Konstantin Komissarchik wrote:
>>>>>> I just double-checked and despite what is said in
Bug 243183, the
>>>>>> JSDT facet is present in Ganymede SR1 (3.0.2) and
in 3.0.3. It
>>>>>> has been removed in the 3.1 HEAD stream for a few
months now, but
>>>>>> the change in the maintenance stream has happened
fairly recently.
>>>>>>
>>>>>>
>>>>>>> surprised by the number of plugin.xmls that
now have to be
>>>>>>> updated to
>>>>>>> prevent this error message.
>>>>>>>
>>>>>> This was the result of the desire to have the JSDT
facet on by
>>>>>> default when a user targets one of the runtimes
that has drivers
>>>>>> shipping with WTP. This meant that this facet had
to be
>>>>>> explicitly included in all the default facet sets
for all the
>>>>>> various server types. In my opinion, this would
have been much
>>>>>> better handled by leaving the facet off by default
and having
>>>>>> some way to unobtrusively tell the user that there
is additional
>>>>>> functionality available when the user goes to
certain contexts.
>>>>>> For instance, if the user opens a _javascript_ file
or you detect
>>>>>> _javascript_ in an html/jsp, you could put an
"Enable advance
>>>>>> _javascript_ support" banner link across the
top of the editor.
>>>>>> That's just my two cents on this.
>>>>>>
>>>>>>
>>>>>>> Even if the facet is added back into 3.0.4,
is/will there be a
>>>>>>> mechanism
>>>>>>> for deprecating or automatically migrating it
out of 3.1 (by M6
>>>>>>> if that's
>>>>>>> the course of action we decide upon)?
>>>>>>>
>>>>>> That depends on what behavior you are after. There
is an
>>>>>> enhancement request (Bug 255038) that was recently
opened that
>>>>>> would allow facets to be marked as deprecated. In
that case you
>>>>>> leave the facet implementation in the code base,
but because it
>>>>>> is marked as deprecated it is not visible on
projects that don't
>>>>>> have it installed already. Project metadata is not
modified
>>>>>> automatically. Other approaches are possible as
well, of course.
>>>>>>
>>>>>>
>>>>>> Oracle
>>>>>> Konstantin Komissarchik | Consulting Member of
Technical Staff
>>>>>> Phone: +1 425 945 8445 | Mobile: +1 206 898 0611
>>>>>> Oracle Eclipse Tooling
>>>>>> 411 108th Ave NE, Suite 800 | Bellevue, WA 98004
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: wtp-dev-bounces@xxxxxxxxxxx
>>>>>> [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Nitin Dahyabhai
>>>>>> Sent: Tuesday, February 03, 2009 6:17 AM
>>>>>> To: wtp-dev@xxxxxxxxxxx
>>>>>> Subject: Re: [wtp-dev] JSDT facet gone missing in
3.0.4?
>>>>>>
>>>>>> Looks like it was removed in 3.0.2 through bug
243183, and at least
>>>>>> noticed at the latest from bug 21928, but not
actually removed
>>>>>> from the
>>>>>> server tools plug-ins. I regret how poorly
this was handled, and am
>>>>>> surprised by the number of plugin.xmls that now
have to be
>>>>>> updated to
>>>>>> prevent this error message.
>>>>>>
>>>>>> Even if the facet is added back into 3.0.4,
is/will there be a
>>>>>> mechanism
>>>>>> for deprecating or automatically migrating it out
of 3.1 (by M6
>>>>>> if that's
>>>>>> the course of action we decide upon)?
>>>>>>
>>>>>> Regards,
>>>>>> ---
>>>>>> Nitin Dahyabhai
>>>>>> Eclipse WTP Source Editing
>>>>>> IBM Rational
>>>>>>
>>>>>> _______________________________________________
>>>>>> wtp-dev mailing list
>>>>>> wtp-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> wtp-dev mailing list
>>>>>> wtp-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> wtp-dev mailing list
>>>> wtp-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>>
>>> _______________________________________________
>>> wtp-dev mailing list
>>> wtp-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
