[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-jst-dev] Notes from today's EJB3 meeting?
|
Hi
Arthur,
Yes, I
understand your points.
A consistent user experience is important and from an EJB 3.0
perspective considering things such as keeping consistency with previous wizard
usage, editors, etc where it makes sense should be part of the plan.
Using existing models is of course important as well, which is why we are doing
what we can to use the existing EMF>>RDB models, while maintaining
the flexibility to extend where necessary for ORM to get the job
done. I think we will definitely want to integrate with your
deployment descriptor models and I think we should talk about these to
understand how things are changing and what needs to be done. The
approach to deployment descriptors is changing a lot in the new EJB spec.
Perhaps in the coming weeks we should get a virtual meeting in place
where we can all review and decide what are the points of integration that make
sense.
I saw
the press release from the JBoss folks on the new tools for the JBoss IDE (
alpha 4 ). I would be interested to hear what parts of this are being
considered for inclusion in the Eclipse project. It does look like they
are using some WTP code base too.
-Robert
Richard,
The inclusion of
the Data tools in WTP was somewhat of a stretch, but we justified on the
grounds that most Web apps access databases and at the time there was no other
Eclipse project to host Data. Also, we focused on the "standards" theme since
the aspects of Data that WTP was focusing on was defined by ANSI (i.e. SQL
editing), and there was JDBC, JSP tags, SQLJ, etc. defined by JCP.
However, when Sybase proposed DTP, we
were the first ones to say that Data tools should move there. We even had a
joint WTP/DTP meeting at EclipseCON. I believe everyone wants Eclipse projects
to have the "right" architecture.
When I say EJB 3.0 should build on the current WTP support for EJB, I
mean that EJB 3.0 should fit in with the existing models, editors, views,
wizards, etc. For example, EJBs are currently rendered as first class J2EE
components in our J2EE Project Explorer view. Also, we have models for all the
J2EE 1.4 deployment descriptors. We are planning to support J2EE 1.5 in our
post WTP 1.0 release.
I think the
optimal way to achieve seamless UI and schedule integration is to host all
aspects of J2EE 1.5 development within the WTP project. There is a lot of
experience in the current WTP team and if we combine this with experts in EJB
3.0, we will achieve the best possible result for Eclipse users and
ISVs.
Arthur Ryman,
Rational
Desktop Tools Development
phone: +1-905-413-3077, TL
969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920,
TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet:
http://labweb.torolab.ibm.com/DRY6/
"Robert Greene"
<rgreene@xxxxxxxxxxx> Sent by: wtp-jst-dev-bounces@xxxxxxxxxxx
06/13/2005 12:29 PM
Please respond
to J2EE Standard Tools developer
discussions |
|
To
| "J2EE Standard Tools
developer discussions" <wtp-jst-dev@xxxxxxxxxxx>
|
cc
| <wtp-jst-dev-bounces@xxxxxxxxxxx>
|
Subject
| RE: [wtp-jst-dev]
Notes from today's EJB3 meeting? |
|
Hi Arthur,
So, it seems I have catching up to do regarding
the WTP subprojects :-)
"The scope of JST
is standards defined by JCP for J2EE, which certainly includes EJB 3.0. Any
project that supports EJB 3.0 should build on the EJB support currently in
WTP. "
[RCG] I think it would be important to understand what
you mean why you say EJB 3.0 projects should "build" upon the current
support. Can we identify the areas that you think are important?
I know some of the things are those which have moved to DTP and we are working
with those, but I suspect there are other areas you are thinking about.
Can you elaborate?
Thanks,
-Robert
-----Original
Message-----
From: wtp-jst-dev-bounces@xxxxxxxxxxx
[mailto:wtp-jst-dev-bounces@xxxxxxxxxxx]On Behalf Of Arthur
Ryman
Sent: Monday, June 13, 2005 7:18 AM
To: J2EE
Standard Tools developer discussions
Cc: wtp-jst-dev@xxxxxxxxxxx;
wtp-jst-dev-bounces@xxxxxxxxxxx
Subject: RE: [wtp-jst-dev] Notes
from today's EJB3 meeting?
Robert,
Nice summary, but I'd like to correct one statement. WTP is not
restricted to J2EE server managed runtimes. It also includes client
programming. In many cases, the client will be a Web application that runs in
a J2EE server, but that is not the only case.
WTP includes the WST subproject
which deals with Web standards and includes tools for client side technologies
such as HTML, _javascript_, and CSS.
Also, the the JST subproject supports clients that
access components that run in J2EE servers or other compliant Web service
servers. For example, the current JAX-RPC spec includes both client and server
programming models. The spec will be split to support client access to Web
services that do not include a full J2EE environement, i.e. the next JAX-RPC
will support J2SE based Web service clients.
The scope of JST is standards
defined by JCP for J2EE, which certainly includes EJB 3.0. Any project that
supports EJB 3.0 should build on the EJB support currently in WTP.
Arthur Ryman,
Rational
Desktop Tools Development
phone: +1-905-413-3077, TL
969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920,
TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet:
http://labweb.torolab.ibm.com/DRY6/
"Robert Greene"
<rgreene@xxxxxxxxxxx> Sent by:
wtp-jst-dev-bounces@xxxxxxxxxxx
06/10/2005 11:53 AM
Please respond
to J2EE Standard Tools developer
discussions |
|
To
| <wtp-jst-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [wtp-jst-dev]
Notes from today's EJB3 meeting? |
|
Hello all,
Below is my
contact info as well.
I am additionally the project manager for this
open source initiative.
I did not take any notes, but can summarize the
main points as I recall them.
(1) There is a belief that this
technology is very application developer centric. I think everyone
agreed on this point.
(2) There is the thought by WTP PMC that
given (1) and the fact that this is based on a J2EE driven spec that it may be
best to host the project within the WTP project.
(3) There are 2
considerations opposing the above.
a) Whether longer term in the
technology adoption lifecycle the use might find it's way closer to the DBA's.
The point was that developers can with this technology ignore the
database, one button click and they are mapped. However, existing schema
and/or the realities of performance and scalability will drive smarter
decisions regarding the selected mapping patterns. Plus there are other
features like named queries where SQL execution plans can be reviewed and
improved by someone who understand the relational schema better (DBA's).
If ORM becomes the predominant way of dealing with the database and
DBA's want to retain control over relational schema and it's access outside of
the language contsructs then they may assume the role of "mapper". I do
not have a strong opinion regarding this point, only wanted to raise the issue
as a valid consideration.
b) Because the ORM technology is spec'ed to
work both inside and outside of application server managed environments and
WTP is very much dedicated to J2EE then perhaps it belongs somewhere else.
One potential "other place" is DTP since this technology is so tightly
coupled with data access in general and ORM was originally defined in it's top
level project proposal. Additionally, the DTP has several code bases
that are integral parts of what is needed by ORM. You can view ORM as a
consumer of DTP components.
(4) Regardless of the above
discussion on where the project belongs longer term, there was a suggestion
that ideally we should only have one project and we ( Oracle, JBoss, Versant,
Others ) should find a way to work together to achieve that goal.
(5) I
suggested a discussion regarding (4) could start by a discussion of where the
interested parties are headed, what is currently implemented and available and
how can those things that are available can be combined to bring a quality
solution to the Eclipse community as in a meaningful timeframe. I
indicated that we are reworking our previous plug-in to be properly integrated
with existing Eclipse project code. We have been heavily focused on full
SWT, forward engineering, annotations, Live ER diagrams, context
sensitive mapping pattern selectivity. The folks from JBoss indicated
that they have been focusing on reverse engineering work.
The following
is a high level overview of what we are doing.
Created the ability to
enable a project for ORM configuration and created a framework for associating
a runtime plug-in with a project. We have created one example of how to
use the framework using our open source EJB runtime. Created a
framework for the context sensitive mapping GUI to reflect the capabilities of
the runtime currently associated with an enabled project. We have used
our open source EJB runtime to show how to use this context sensitive GUI
framework. Created synchronized views of mapping information ( source
code editors, mapping pattern editors, live ER editors ) where a change
in any view is reflected in the others. So, for example if someone adds
an annotation to the source code the appropriate mapping possibilities
automatically appear in the mapping view and the default mapping is selected
and represented by a live ER diagram. Created an extensible framework
for allowing vendors to provide customizable input output capabilities to
accommodate alternative runtimes. Used this framework to show an example
of outputting meta data for our open source EJB runtime. All of this is
driven by an EMF model that vendors may extend to suit their
needs.
Rather than working on reverse engineering over the last 6
weeks, the proposed JSR220 committers have been reworking to integrate with
Eclipse code base. Given that the JBoss group has done a lot around
reverse engineering, perhaps this is one starting point for looking at
integrating the code bases? In recent additions to the Oracle
proposal, I have seen some screen shots of expected capabilites. Perhaps
we can talk about these in more detail and understand what has been done so we
can understand overlap with JBoss and Versant stuff. Then we could fill
in the holes on a phase 1 of a complete solution.
-Robert
Robert Charles Greene
Vice President,
Product Strategy
Versant Corporation
6539 Dumbarton Circle
Fremont,
CA 94555
Office: (510)789-1627
Mobile:
(925)577-4634
_______________________________________________
wtp-jst-dev
mailing
list
wtp-jst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev
_______________________________________________
wtp-jst-dev
mailing
list
wtp-jst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev