> 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: [email protected] [mailto:[email protected]] 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 [email protected] From: "Konstantin Komissarchik" <[email protected]> To: "'General discussion of project-wide or architectural issues.'" <[email protected]> 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: [email protected] [ <mailto:[email protected]> mailto:[email protected]] 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> 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:[email protected]> mailto:[email protected]] Sent: Tuesday, >>>>> February 03, 2009 8:49 PM >>>>> To: [email protected]; 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: [email protected] >>>>>> [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of Nitin Dahyabhai >>>>>> Sent: Tuesday, February 03, 2009 6:17 AM >>>>>> To: [email protected] >>>>>> 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 >>>>>> [email protected] >>>>>> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>>>>> >>>>>> _______________________________________________ >>>>>> wtp-dev mailing list >>>>>> [email protected] >>>>>> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> wtp-dev mailing list >>>> [email protected] >>>> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev >>> >>> _______________________________________________ >>> wtp-dev mailing list >>> [email protected] >>> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev >> >> _______________________________________________ >> wtp-dev mailing list >> [email protected] >> <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev > > _______________________________________________ > wtp-dev mailing list > [email protected] > <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list [email protected] <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev _______________________________________________ wtp-dev mailing list [email protected] <https://dev.eclipse.org/mailman/listinfo/wtp-dev> https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/wtp-dev
