[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
-----Message d'origine-----
De : wtp-jst-dev-bounces@xxxxxxxxxxx
[mailto:wtp-jst-dev-bounces@xxxxxxxxxxx]De la part de
wtp-jst-dev-request@xxxxxxxxxxx
Envoye : mardi 14 juin 2005 18:01
A : wtp-jst-dev@xxxxxxxxxxx
Objet : wtp-jst-dev Digest, Vol 2, Issue 5
Send wtp-jst-dev mailing list submissions to
wtp-jst-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev
or, via email, send a message with subject or body 'help' to
wtp-jst-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
wtp-jst-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of wtp-jst-dev digest..."
Today's Topics:
1. unsubscribe (SOUCHET Laurent ROSI/SICOR)
----------------------------------------------------------------------
Message: 1
Date: Tue, 14 Jun 2005 09:34:10 +0200
From: "SOUCHET Laurent ROSI/SICOR" <laurent.souchet@xxxxxxxxxxxxxxxxx>
Subject: [wtp-jst-dev] unsubscribe
To: <wtp-jst-dev@xxxxxxxxxxx>
Message-ID: <00bc01c570b3$7517ad30$cdc2920a@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
-----Message d'origine-----
De : wtp-jst-dev-bounces@xxxxxxxxxxx
[mailto:wtp-jst-dev-bounces@xxxxxxxxxxx]De la part de
wtp-jst-dev-request@xxxxxxxxxxx
Envoye : lundi 13 juin 2005 19:34
A : wtp-jst-dev@xxxxxxxxxxx
Objet : wtp-jst-dev Digest, Vol 2, Issue 4
Send wtp-jst-dev mailing list submissions to
wtp-jst-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev
or, via email, send a message with subject or body 'help' to
wtp-jst-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
wtp-jst-dev-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of wtp-jst-dev digest..."
Today's Topics:
1. RE: Notes from today's EJB3 meeting? (Robert Greene)
2. RE: Notes from today's EJB3 meeting? (Arthur Ryman)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Jun 2005 09:29:25 -0700
From: "Robert Greene" <rgreene@xxxxxxxxxxx>
Subject: RE: [wtp-jst-dev] Notes from today's EJB3 meeting?
To: "J2EE Standard Tools developer discussions"
<wtp-jst-dev@xxxxxxxxxxx>
Cc: <wtp-jst-dev-bounces@xxxxxxxxxxx>
Message-ID:
<DED902689A686B4A8BE0775EC554D598013A05D9@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
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 al
ternative 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eclipse.org/pipermail/wtp-jst-dev/attachments/20050613/216ae411/attachment.html
------------------------------
Message: 2
Date: Mon, 13 Jun 2005 13:34:01 -0400
From: Arthur Ryman <ryman@xxxxxxxxxx>
Subject: RE: [wtp-jst-dev] Notes from today's EJB3 meeting?
To: J2EE Standard Tools developer discussions
<wtp-jst-dev@xxxxxxxxxxx>
Cc: "J2EE Standard Tools developer discussions"
<wtp-jst-dev@xxxxxxxxxxx>, wtp-jst-dev-bounces@xxxxxxxxxxx
Message-ID:
<OF1D1E9B32.28C2767F-ON8525701F.005EC4C7-8525701F.00607F05@xxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eclipse.org/pipermail/wtp-jst-dev/attachments/20050613/d5baf177/attachment.html
------------------------------
_______________________________________________
wtp-jst-dev mailing list
wtp-jst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev
End of wtp-jst-dev Digest, Vol 2, Issue 4
*****************************************
------------------------------
_______________________________________________
wtp-jst-dev mailing list
wtp-jst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev
End of wtp-jst-dev Digest, Vol 2, Issue 5
*****************************************