Comments inline...
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Monday, April 17, 2006 4:51
PM
To: General discussion of project-wide
or architectural issues.
Subject: RE: [wtp-dev] Enablement
_expression_ support in validator ext point
Why would this deprecation message ever have to be part
of the log that is sent to support? Its not doing them, or the user, any good.
[kk] End users and support are not
the only consumers of the PDE Error Log. In fact I view the primary consumers
as the developers and the test org.
Tim has given one example, and,
I, as another battled-scared committer of this mistake, have had "real
life" experience ... I did something similar once, and probably got
5 or 10 "official" support phone calls about "what does this
warning mean", my customer is wondering if its related to the bug they are
having (and while obvious to developers it wasn't related ... it is not so
obvious to support people or customers) ... and I must have gotten 20 similar
calls from "add on" providers -- so, I think the cost of confusion
outweighs the benefits.
[kk] To
be honest, I don’t see anything wrong with what you are describing. Problems
that publicize themselves effectively are more likely to get fixed than those
that are hidden. Before the product reaches end users, it is in the hand of the
dev and test orgs. If the dev and test orgs have punted on fixing these
warnings before shipping the product, then perhaps they shouldn’t be
surprised by the support calls. It might be harsh, but it gets the use of
deprecated functionality eliminated quickly rather than letting it linger. In
the end everyone is happier as there are no surprises when the deprecated
functionality is removed. So I don’t think that the described confusion
outweighs the benefits.
So, I don't see it as
"theoretical" ... There's better mechanisms for both deprecations
warnings and for plugin developer aides. Let's use them.
[kk]
Unfortunately, there isn’t a better mechanism. The only mechanism
available is “deprecated” flag on the extension point schema.
Unfortunately, the way it is implemented, you have to really try to see the
deprecation warnings. Even having the plugin project in your workspace does not
produce the warning. You have to open the plugin.xml file in order to see it.
That’s unacceptable. The likelihood that the use of deprecated
functionality will go unnoticed, especially in plugins that are not under active
development is rather high. On the other hand, when I implemented my
deprecation checks, the first time I launched Eclipse, I saw in the log the
list of plugins that were using the deprecated functionality. I was able to
very quickly go through and update all of them. I didn’t need to load all
of wtp codebase into my workspace and then manually open each plugin.xml file
to see if there were any warnings. The end result was that usage of deprecated
functionality was eliminated very quickly instead of lingering.
And
.. careful .. if you have strong views on logging, I am looking for someone to
own the logging strategy for WTP :)
[kk] I
have no particular interest in logging. I am very interested in facilitating
smooth api evolution, which requires that deprecated functionality is remove
next release after deprecation, which in turn requires that the usage of
deprecated functionality is eliminated as quickly as possible.
"Konstantin
Komissarchik" <kosta@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
04/17/2006 06:56 PM
Please
respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [wtp-dev] Enablement _expression_ support
in validator ext point
|
|
I disagree. PDE error log is not an end-user
tool. It’s meant to help plugin authors identify problems that occur at
runtime. As in support directing the customer to send the error log to them for
trouble shooting. Your average user should not have any need to look at the log
(it’s hidden by default). If they do, that just means that we are not
doing our jobs.
Regarding the particular question of using the log to report
deprecation warnings, I believe that this is not inconsistent with what the PDE
error log is supposed to be used for and is the best tool we have for making
sure that usage of deprecated functionality does not go unnoticed by the plugin
owner. Everyone is happier when there are fewer surprises as the deprecated
functionality is removed in the next release. I also don’t agree that this
hides real errors as there is very good visual separation between warnings and
errors and deprecation reporting only needs to produce one message per
extension point / plugin combination (not a lot).
- Konstantin
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: Monday, April 17, 2006 3:38 PM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Enablement _expression_ support in validator
ext point
I agree with Tim. We should only log things we think users/consumers should see
... otherwise, please "hide" unless turned on with some
explicit -debug .facet-options flag.
(and, encourage *developers* to clean up their warnings, and/or turn on
deprecated extension points to the 'error' level -- PDE i s your friend :)
Timothy Deboer
<deboer@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
04/17/2006 04:00 PM
Please
respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [wtp-dev] Enablement _expression_ support
in validator ext point
|
|
Hi,
While I agree that a little incentive helps to move people off deprecated API,
deprecated Java code doesn't produce output at runtime and I'm not sure that
extension points should. Throwing everything out to the .log hides real errors
and can produce a lot of extraneous output. When the similar change was made in
facets I received several email from panicked users who thought WTP was failing
or blamed other problems on the errors in the log.
Thanks,
Tim deBoer
WebSphere Tools - IBM Canada Ltd.
(905) 413-3503 (tieline 969)
deboer@xxxxxxxxxx
"Konstantin
Komissarchik" <kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
17/04/2006 02:14 PM
Please
respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
<wtp-dev-bounces@xxxxxxxxxxx>
|
Subject
|
RE: [wtp-dev] Enablement _expression_ support
in validator ext point
|
|
Vijay,
You may want to consider logging deprecation warnings into PDE Error Log when
the deprecated extension syntax is detected. The deprecation warning should
include the id of the plugin that the deprecated syntax is used in. This way
the plugin owner is more likely to become aware that they are using deprecated
syntax and will transition to the new syntax more quickly.
I have done this for all the syntax that I have deprecated in the faceted
project framework.
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Vijay Bhadriraju
Sent: Monday, April 17, 2006 11:07 AM
To: General discussion of project-wide or architectural issues.
Cc: General discussion of project-wide or architectural issues.;
wtp-dev-bounces@xxxxxxxxxxx
Subject: Re: [wtp-dev] Enablement _expression_ support in validator
ext point
Yes, enablement is the recommended way to filter validators based on facets,
the facet filters has been deprecated but will continue to work.
Regards, Vijay
_____________________________
Vijay Bhadriraju
Rational Tools, J2EE Tooling
Ph: (919) 486-1898, T/L: 526-1898
Internet: vbhadrir@xxxxxxxxxx
_____________________________
Lawrence Mandel <lmandel@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
04/17/2006 12:10 PM
Please
respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
To
|
"General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
Re: [wtp-dev] Enablement _expression_ support
in validator ext point
|
|
Hi Vijay,
Is the enablement method now the recommended way to restrict based on facets?
Has the facet filters support been deprecated?
Thanks,
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
Vijay Bhadriraju
<vbhadrir@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
04/16/2006 10:52 PM
Please
respond to
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
|
To
|
wtp-dev@xxxxxxxxxxx
|
cc
|
|
Subject
|
[wtp-dev] Enablement _expression_ support in
validator ext point
|
|
The support for enablement _expression_ as shown below has been added to the
validator extension point. The facet filters support added in the validator ext
point in addition to natures did not scale very well and additional
requirements from some extended teams drove the need for the enablement support
which scales very well. This _expression_ support covers all the
combinations that the FacetedProjectPropertyTester
provides as this is the tester class that is used under the covers for property
and value strings.
The ejb validator is changed to use this support instead of facet filters
<extension
id="EJBValidator"
name="%EJB_VALIDATOR"
point="org.eclipse.wst.validation.validator">
<validator>
<enablement>
<and>
<test property="org.eclipse.wst.common.project.facet.core.projectFacet"
value="jst.java"/>
<test property="org.eclipse.wst.common.project.facet.core.projectFacet"
value="jst.ejb"/>
</and>
</enablement>
<filter
objectClass="org.eclipse.core.resources.IFile"
nameFilter="ejb-jar.xml">
</filter>
<filter
objectClass="org.eclipse.core.resources.IFile"
nameFilter="*.class">
</filter>
<filter
objectClass="org.eclipse.core.resources.IFile"
nameFilter="*.java">
</filter>
<helper
class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.EJBHelper">
</helper>
<dependentValidator
depValValue="true">
</dependentValidator>
<markerId
markerIdValue="EJBValidatorMarker">
</markerId>
<run
class="org.eclipse.jst.j2ee.internal.ejb.workbench.validation.UIEjbValidator">
</run>
</validator>
</extension>
The facet filters support still exists and works in the validator ext point
even though it is redundant with this enablement support. The reason it is
still supported is for the fact that we are not supposed to break any internal
api also at this point for 1.5. Validators using facet filters will continue to
work as is and the any validators that need the enablement _expression_ support
can migrate.
Regards, Vijay
_____________________________
Vijay Bhadriraju
Rational Tools, J2EE Tooling
Ph: (919) 486-1898, T/L: 526-1898
Internet: vbhadrir@xxxxxxxxxx
_____________________________ _______________________________________________
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
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries
and affiliated
entities, that may be confidential, proprietary, copyrighted
and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
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
_______________________________________________________________________
Notice: This email message, together with
any attachments, may contain
information of BEA Systems,
Inc., its subsidiaries and affiliated
entities, that may be confidential,
proprietary, copyrighted and/or
legally privileged, and is intended solely for the
use of the individual
or entity named in this message. If you are not
the intended recipient,
and have received this message in error, please
immediately return this
by email and then delete it.
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev