[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-dev] Enablement expression support in validator ext point
|
I don't have a problem with this but
I think that you've only got a short amount of time to have this enabled
in the build. I think this should be disabled in RC2 as RC3 and on will
start the real stabilization of WTP and the approval process for bugs.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
"Konstantin Komissarchik"
<kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
04/20/2006 01:31 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 |
|
John,
Thanks for chiming in. I like
your compromise solution. It gives wider exposure to deprecated api during
the development cycle yet avoids confusing end users using the released
bits.
I am not sure why I am having
difficulties seeing the PDE deprecation warnings. I am using 3.2 M6. Perhaps
it’s something about my workspace...
One advantage of runtime deprecation
warnings is that it is not necessary to have the source in your workspace
in order to see the warnings. I don’t know how everyone else works, but
I typically pull in projects into my workspace as I need to work on them
and delete them when I am done. This means that if there is a plugin that’s
not regularly worked on, the author might not become aware of the deprecated
api.
So why is it important to become
aware of api deprecation? By its definition, deprecated api will cease
to be supported (aka removed) at some point in the future. For how many
releases a deprecated api is supported depends on the maturity of the api.
Very mature API’s that change very infrequently can afford to support
deprecated functionality indefinitely. Young developing API’s need flexibility
to evolve rapidly on the road to stability and maturity. This means that
developing API’s cannot afford to support deprecated api for a very long
time. At the same time, no one likes when their code gets broken by an
API change, so I will postulate that as the deprecation support window
shortens the loudness of the deprecation warnings should increase.
The api in question (faceted
project framework) is provisional, meaning it’s a young rapidly-evolving
api. For api deprecated during the 1.5 release, I plan to support it through
the end of 1.5 and then remove it at the start of the 2.0 release cycle.
That’s a relatively short time frame, but is necessary in order to allow
the api to evolve unencumbered. Hence also is my desire to broadcast the
deprecation as clearly as possible. I don’t want anyone surprised.
So here is what I’d like to
do... I will create a tracing flag that will control the display of these
deprecation warnings. The default value for the tracing flag will be on
until just prior to 1.5 release at which point it will default to off.
Any serious objections from anyone?
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent: Tuesday, April 18, 2006 7:53 AM
To: General discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Enablement _expression_ support in validator ext
point
My two cents: I agree with Konstantin that the primary audience of the
error log is plugin developers. This is clear from the typical entries
one sees in the log: problem severities are encoded in unreadable integer
form, messages are often not written in a form that users will understand,
and as a general rule messages in the log are not translated. If
there are problems that may occur at runtime for which there is no tooling
support to catch at build time, then it is worth adding log entries for
them. However, I don't think deprecation falls into that category.
Konstantin, it's possible you have some settings changed that makes
it hard to see deprecations, but in practice it is just as easy to see
deprecation warnings in extensions as it is for Java code. Warning
markers are generated by PDE, and they appear in both the editors and the
problems view. By default the severity is warning, but it can be
set to error if you really want them to stand out (Preferences > Plugin
Development > Compilers > Plugins > Usage of deprecated attributes
and elements). Assuming usage of the deprecated elements has no adverse
side-effects at runtime, then I think the development time tooling support
should be sufficient. Just imagine the log output if we started logging
on each use of deprecated Java methods ;)
A possible trade-off: if there is a significant reason to get off the deprecated
API (such as performance problems or loss of functionality), you could
consider logging these warnings for awhile in development builds, but then
turning it off for the final release. We have done similar things
in the past in the platform to kick people into action - adding warnings
in the log for a milestone or two, but turning it off in the final release
to avoid the flood of support calls.
John
Lawrence Mandel/Toronto/IBM@IBMCA
Sent by: wtp-dev-bounces@xxxxxxxxxxx
18/04/2006 01:41 AM
Please respond to
"General discussion of project-wide or architectural issues." |
|
To
| "General discussion
of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [wtp-dev] Enablement
_expression_ support in validator ext point |
|
>[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.
I think you're making a big assumption here that every developer/organization
wants to update their plug-in(s) immediately from the deprecated API. There
are valid reasons for staying on deprecated API and it should be up to
WTP's adopters to decide when they move off of deprecated API. Also, I
don't think it's fair or right to burden WTP's adopters with extra support
calls because you don't want them to use the deprecated API. We should
support deprecated API for "a long time" after it's declared
deprecated and shouldn't punish those that continue to use it with extra
support costs.
And, BTW, I've dealt with many Eclipse users (several at EclipseCon this
year) who are comfortable troubleshooting by looking through the log and
do not develop plug-ins.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
"Konstantin Komissarchik"
<kosta@xxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
04/17/2006 08:41 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 |
|
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
_______________________________________________________________________
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