I wish we can get it in for M5. But, it is
not a requirement. My suggested solution will be backward compatible. I send
out the proposal this week, because I wish it can be discussed in EclipseCon
where a few WTP devlopers would attend.
Btw,
http://www.eclipse.org/webtools/development/planning/roadmap.html
The roadmap doc on wtp site is a bit
outdated.
Thomas
From:
wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Brad Blancett
Sent: Tuesday, March 21, 2006
11:05 AM
To: General
discussion of project-wide or architectural issues.
Subject: RE: [wtp-dev] Re: Server
API change proposal
Thomas,
this defect is targeted for 1.0.1: "WTP 1.0.1 which was officially
released on 2006-02-24".
Api
freeze for 1.5 was M4 - January 13, 2006 * M5 -March 3, 2006
(planned API freeeze).
If this
proposal is accepted, what version of wtp would this be targeted against?
Brad Blancett
Rational Tooling
Tie 3-2650
External 919-543-2650
|
"Thomas Yip"
<tyip@xxxxxxx>
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
03/21/2006 01:32 PM
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] Re:
Server API change proposal
|
I certainly agree publishing at app level is more
natural. But, I think
the need of very simple publish delegate is also
valid. WTP potentially
support other Server type...
Thomas
> -----Original Message-----
> From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]
On
> Behalf Of Sachin Patel
> Sent: Tuesday, March 21, 2006 6:04 AM
> To: General
discussion of project-wide or architectural issues.
> Subject: [wtp-dev] Re: Server API change
proposal
>
> I personally think publishing at the app
level is a more natural/
> logical approach and the need of a second
delegate class should be
> only temporary until other server adapters
can conform to this
> proposal. I also have some concerns on
how the delta is managed and
> flushed, but need some time to gather my
thoughts so that can be
> discussed later.
>
> - sachin
>
>
>
> On Mar 20, 2006, at 7:01 PM, Thomas Yip
wrote:
>
> > Introduction
> > This proposal briefs the limitation we
see with current server
> > publish API, and it suggests a solution.
We had a short discussion
> > during a conference call on Mar 13th,
2006. (mainly around the
> > ServerBehaviourDelegate). The problem is
also related to https://
> >
bugs.eclipse.org/bugs/show_bug.cgi?id=123676
> >
> >
> >
> > Current API
> > We learned the original design was
driven by a need of a very
> > simply publish mechanism.
> >
> > an adopter should able to implement a
simply delegate and do the
> > publish work.
> > publish tasks was intent to be simple task.
> > most methods can be overridden.
> >
> >
> > BEA use-cases
> > We found the current API is not ideal
for BEA needs.
> >
> >
> >
> > We delay much of publish process until
user do an explicit publish
> > action (menu item publish, or Run on
Server).
> >
> >
> >
> > We generates *.java file based on
annotation of Java file in
> > publish time. We trigger project rebuild
during process.
> > We insert information into application
descriptors (web.xml,
> > application.xml) based on files on the
project.
> > Generated artifacts can cause changes to
the EAR or other modules
> > in the same application.
> > Publish application by application.
> > Publish failure should be isolated
between modules.
> >
> >
> > For us, the publish process is better
described as a 3 steps
> > process: Assembly (artifact generation),
Packaging (we package
> > virtually), and Distribution (calls
JSR-88 to distribute the
> > application to the server).
> >
> > Limitation
> > The current SPI was driven by the need
of simple publishing. The
> > publish process iterates module by a
flattend module list (not
> > application by application.)
> >
> >
> >
> > Because that most methods can be
overridden, we can achieve our
> > goal reasonably well. However, it incurs
maintenance risk, because
> > are not really implementing the
delegate's SPI. For example,
> >
> > if a fix or an enhancement is made to
PublishOperation, our server
> > adapter lag behind, and enhancement will
not be supported.
> > We short circuit a few methods, such as
publishModules() (which is
> > a violate the interface). If any of the
methods is called by new
> > code that we haven't overridden, it
causes unexpected behaviour.
> >
> >
> > Because of the different design goal, we
don't implement the full
> > spec of ServerBehaviourDelegate. While
such changes might not be
> > likely, an adopter should not be
required to implement their
> > delegate in a way to violate the SPI
contract.
> >
> > SolutionRequired changes
> > We can eliminate the problem by the
following changes:
> >
> >
> >
> > Introduce another delegate. Let's call
it
> > BaseServerBehaviourDelegate for now. The
current
> > ServerBehaviourDelegate should make
extended of
> > BaseServerBehaviourDelegate. Most
generic methods can be push up.
> > (such as state settings, module
controls, resource delta
> > maintaince. But, it leaves out
> > code related to published module list,
and the kind.
> > PublishOperation, and
> > all the publish methods. Introduce an
adapter interface to indicate
> > PublishOperation is supported.
> >
> >
> > The changes will maintain compatibility
for all current adopter,
> > and the original design goal. It enables
adopter with different
> > needs to have full control of the
publish process.
> >
> >
> >
> >
> > Either, makes publish operation
optional. Push down
> > PublsihOperation related code to the
original ServerBehaviour
> > Delegate.
> > Or, factors out PublishOperation into
utility class or method.
> > Or, made PublishOperation not depends on
the flatten module path
> > (IModule[] representing the sub module
and its parents).
> > Introducing another extension point for
UI to replace the hard-
> > coded publishTask page fragment. Move UI
for publishOperation as an
> > extension.
> >
> >
> > A brief study of the code indicated that
we should able to
> > implement it in a way that it doesn't
affect existing adopter.
> >
> >
> >
> > Optional changes
> > A few optional changes can be introduced
to ease the work of an
> > adopter.
> >
> >
> >
> > Publishing application-by-application is
common to many servers. We
> > might want to introduce another
BehaviourDelegate.
> > Generic server is already use
application-by-application approach.
> > We should look into merging the
requirements.
> > Going further, we can also introduce the
3 steps publish process
> > for adopter with complicated publish
use-case.
> >
> >
> >
> >
> >
> >
> > --------------------
> >
> > Thomas Yip
> >
> > Senior Software Engineer
> >
> > BEA Systems
> >
> > Email: tyip@xxxxxxx YIM:
thomasleaf Phone: (206) 926-2906
> > Blog: http://theBigGrid.com/
> >
> >
> >
> > "The complexity you remove can
never fail." Burt Rutan.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
______________________________________________________________________
> > _ 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
_______________________________________________________________________
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.
|