[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-dev] Java EE Tools discussion - wiki page
|
Hi,
I have setup the wiki page for the JEE Status
Meetings:
I have also created a page for the meeting minutes from our
meeting in Wednesday:
I
haven't taken notes on the meeting and the minutes are quite basic. Please, feel
free to add notes to the Attendees and Minutes sections.
Greetings,
Kaloyan
Hi Naci, Phone details are listed below in this thread
Thanks - Chuck
Rational Java EE
Tooling Team Lead
IBM Software Lab - Research Triangle Park,
NC
cbridgha@xxxxxxxxxx Ph: 919-254-1848 (T/L: 444)
From:
| "Naci Dai"
<naci.dai@xxxxxxxxxxxxx>
|
To:
| "General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
Date:
| 07/15/2008 11:49 AM
|
Subject:
| Re: [wtp-dev] Java EE Tools discussion
(Wednesday 11am - 12pm EDT) |
Chuck,
What are the coordinates of the
meeting?
On Tue, Jul 15, 2008 at 5:07 PM, Chuck
Bridgham <cbridgha@xxxxxxxxxx> wrote:
OK,
Sorry for the late notice - We are trying to get most
parties involved in the discussion, so I will move the meeting to 11am EDT
Wednesday (Tomorrow)
Tim - I know you will miss, but I'll catch up with you
later.
Thanks -
Chuck
Rational Java EE Tooling Team Lead
IBM Software Lab - Research
Triangle Park, NC
cbridgha@xxxxxxxxxx
Ph: 919-254-1848 (T/L: 444)
I'm going to be
out Wed/Thursday, and flying on Friday. Looks like we need to have a meeting
without some of us, or try next week.
Tim deBoer
Eclipse WTP PMC, RAD Release
Architect and WebSphere Tools - IBM Canada
(905) 413-3503 (tieline
969)
deboer@xxxxxxxxxx
It turns out
that tuesday morning doesn't work for me at all this week. How about Wednesday
morning instead?

Konstantin Komissarchik | Principal Member of Technical
Staff
Phone: +1 425 201 1795 | Mobile: +1 206 898 0611
Oracle Eclipse Tooling
411 108th Ave NE, Suite 2100 | Bellevue, WA 98004
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Raev, Kaloyan
Sent: Monday, July 14, 2008
5:36 AM
To: General discussion of project-wide or architectural
issues.
Subject: RE: [wtp-dev] Java EE Tools discussion (Tuesday 11am
- 12pm EDT)
I think this is now
in conflict with the WTP PMC call where I attend.
Is it possible to make
this call one hour later? It is not a problem for me to stay one more hour in
the office.
If the change is not possible for everybody, I will try to skip
the PMC call.
Greetings,
Kaloyan
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Chuck Bridgham
Sent: Monday, July 14,
2008 2:30 PM
To: General discussion of project-wide or architectural
issues.
Subject: [wtp-dev] Java EE Tools discussion (Tuesday 11am -
12pm EDT)
Sorry didn't get this
out in time, so lets have it Tuesday same time (11am EDT)
Java EE tools
discussion.
Topics: Mixing spec levels in EAR. Opinions?
Planning...
DIAL-IN NUMBERS & PASSCODES:
US/Canada Toll Free:
877-421-0030
International call-in: http://wiki.eclipse.org/images/f/f6/WTP_status_phone_access.pdf
Participant
Passcode: 631004
Thanks - Chuck
Rational Java EE
Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
cbridgha@xxxxxxxxxx
Ph: 919-254-1848 (T/L: 444)
Yes sorry - I can do it tomorrow or
Monday.
Any
preference?
Thanks - Chuck
Rational Java EE Tooling Team Lead
IBM
Software Lab - Research Triangle Park, NC
cbridgha@xxxxxxxxxx
Ph: 919-254-1848 (T/L: 444)
I think we have lost the thread
here...
Chuck,
what is the soonest day you can organize a telecon in the 8:00 AM to 9:00
AM PDT timeslot?
Greetings,
Kaloyan
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: Thursday,
July 03, 2008 7:17 PM
To: General discussion of project-wide or
architectural issues.; Chuck Bridgham
Subject: RE: [wtp-dev] Mixing
spec levels in EAR. Opinions?
Next week works ok for me and I suppose I can do 8 AM PDT if
that's absolutely the only time that makes sense for everyone else.
-
Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Raev, Kaloyan
Sent: Wednesday, July 02,
2008 9:21 AM
To: Chuck Bridgham
Cc: General discussion of
project-wide or architectural issues.
Subject: RE: [wtp-dev] Mixing
spec levels in EAR. Opinions?
Hi Chuck,
Does this mean you can organize the telecon any
day after Thursday from 8:00 AM to 9:00 AM PDT?
Greetings,
Kaloyan
From: Chuck Bridgham [mailto:cbridgha@xxxxxxxxxx]
Sent: Wednesday, July 02, 2008 4:58 PM
To: Raev,
Kaloyan
Cc: General discussion of project-wide or architectural
issues.
Subject: RE: [wtp-dev] Mixing spec levels in EAR.
Opinions?
Hi,
This Thursday doesn't work for me,
but I can meet next week, any day at the same time mentioned.
Thanks -
Chuck
Rational Java EE Tooling Team Lead
IBM Software Lab - Research
Triangle Park, NC
cbridgha@xxxxxxxxxx
Ph: 919-254-1848 (T/L: 444)
From:
| "Raev, Kaloyan" <kaloyan.raev@xxxxxxx>
|
To:
| Chuck Bridgham/Raleigh/IBM@IBMUS,
"General discussion of project-wide or architectural issues."
<wtp-dev@xxxxxxxxxxx>
|
Date:
| 07/02/2008 08:13 AM
|
Subject:
| RE: [wtp-dev] Mixing spec levels in EAR.
Opinions? |
It really seems we need a phone
call...
Chuck, I remember we had phone calls when discussing JEE5 more
than year ago. Is it possible to use the same teleconference for this
topic?
As far
as I remember the time slot was on Thursday, 8:00 AM - 9:00 AM PDT.
Greetings,
Kaloyan
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: Tuesday,
July 01, 2008 7:13 PM
To: General discussion of project-wide or
architectural issues.
Subject: RE: [wtp-dev] Mixing spec levels in
EAR. Opinions?
I still haven't
heard a viable argument for why this restriction is necessary. Allowing ear
facet version changes does not completely address the scenario that I presented.
In a large and complicated app, the user may not be ready to upgrade the ear
spec level. That may be quite an undertaking. Regarding the relationship between
facet version and descriptor schema, anything other than strict 1-to-1
relationship can lead to all sorts of problems in both WTP and adopter code. It
should be considered an error case. Sounds like we need a phone
call.
-
Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Raev, Kaloyan
Sent: Tuesday, July 01,
2008 5:41 AM
To: General discussion of project-wide or architectural
issues.
Subject: RE: [wtp-dev] Mixing spec levels in EAR.
Opinions?
Tim, Konstantin,
thank you for your comments.
I agree with Tim that the facet version of
the EAR should be considered as the max spec level of the modules that this EAR
can include. This sounds nice in terms of validation.
On the other side
I agree with the scenario given by Konstantin. At the moment the users really
cannot upgrade an existing EAR 1.4 to EAR 5 and add EE 5 modules to it.
So, the solution in this situation I see to be that we allow upgrading
the facet version of EAR projects. Then we can do a strict validation/filtering
based on the EAR's facet version and at the same time have the Konstantin's
scenario possible. How hard would it be to introduce this? I even see two
possible option:
1) upgrading EAR facet version without upgrading the DD (should be
quite simple)
2) upgrading EAR facet version and upgrading the DD
Greetings,
Kaloyan
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Konstantin Komissarchik
Sent: Friday,
June 27, 2008 7:14 PM
To: General discussion of project-wide or
architectural issues.
Subject: RE: [wtp-dev] Mixing spec levels in
EAR. Opinions?
Here are my
views on the subject...
Given that the spec is ambiguous, the question that should be
asked is "is there at least one runtime that supports this scenario"? If the
answer is yes for at least one runtime, then in order to follow WTP charter and
not preclude proper integration of that runtime with WTP, we have to take a more
allowing stance on this. There is indeed at least one runtime that has no
problem with this scenario. I just had someone verify that WLS does in fact
support it.
The situation is made worse by the fact that we still have no
support for spec level changes, so users can get stuck. The following scenario
is not that uncommon:
1. User has an existing j2ee 1.4 app.
2. User needs to add a new
module.
3.
User wants to take advantage of java ee 5 features in new code.
We should not be
getting in the way of this scenario. If particular servers do not support this,
then server adapters for those servers can perform that validation and alert the
user.
-
Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On Behalf Of Tim deBoer
Sent: Thursday, June 26, 2008
10:07 AM
To: General discussion of project-wide or architectural
issues.
Subject: Re: [wtp-dev] Mixing spec levels in EAR.
Opinions?
Hi Kaloyan,
Thank you for raising this
issue. I agree we are inconsistent in parts, and although we don't necessarily
need to resolve all of the issues immediately we should at least have a common
definition of what is 'correct' and may eventually be supported by
WTP.
Among the
IBM committers we generally agree with #2, but have made an interesting
distinction: the schema used by a DD is only a bottom boundary on the spec level
of the EAR or module. As an example, a '1.4' EAR that contains an EJB 3.0 module
is really just an EE 5 EAR (or EE 6.0 or ...) with an older DD. Likewise, EJB
3.0 annotations within an EJB module is an indication that the EJB is at least
EE 5/EJB 3.0, even if the DD still points to the EJB 2.0 schema.
If DD schemas and spec API
usage are just a bottom boundary, it means that there is nothing within the
contents of an EAR or module that can precisely determine its level. So how do
we tell if it is valid for a user to add an EJB 3.0 module to what currently
looks like a 1.4 EAR? Was it really an EE 5 EAR all along, do they want to
uplevel the EAR, or is the user simply making a mistake?
The solution we came to is using
facets. Facet versions allow the user to tell us which spec level they expect an
EAR/module to be at, and gives us something to tool for and validate against.
The versions are set on project creation or on import based on what we initially
find in the modules. >From there, the facet version of an EAR determines the
maximum spec level of modules that can be added or which servers it can be run
on, and validation can show errors for invalid modules or if the DD points to a
schema above the level of the facet.
If you agree with the original distinction (that
true EAR 1.4s can't hold EJB 3 modules, but the schema used by the DD is only a
bottom boundary on the spec level), then I think you'll eventually come to the
same conclusion we have. Please feel free to let me know what you think and
others can chime in, or we can discuss on one of the WTP calls.
Thanks,
Tim
deBoer
deboer@xxxxxxxxxx
From:
| "Raev, Kaloyan" <kaloyan.raev@xxxxxxx>
|
To:
| "General discussion of project-wide or
architectural issues." <wtp-dev@xxxxxxxxxxx>
|
Date:
| 06/26/2008 09:04 AM
|
Subject:
| [wtp-dev] Mixing spec levels in EAR.
Opinions? |
Hello,
I want to bring up again an issue
that was discussed some time ago in
Bugzilla. It is about mixing of spec
levels of EAR and included modules.
There are two bugs
related:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=220929
https://bugs.eclipse.org/bugs/show_bug.cgi?id=229893
Everybody agree that EAR with spec level X could include modules
with
spec level X or lower. Example: EAR 5 can include EJB 2.1.
But there
is no consensus of opinion on EAR with spec level X to include
modules with
spec level higher than X. Example: EAR 1.4 to include EJB
3.0. There are two
contrary opinions:
1. EAR 1.4 can include EJB 3.0
2. EAR 1.4 cannot
include EJB 3.0.
The supporters of opinion 1 says that it is not
forbidden by the Java EE
spec.
The supporters of opinion 2 says that it
is (at least indirectly)
forbidden by the spec. This is because the contract
of the Java EE spec
says that a deployment module compliant with spec level X
must always be
able to deploy on an application server compliant with spec
level X. Now
let's look again at our example of EAR 1.4 including EJB 3.0.
EAR 1.4 is
a J2EE 1.4 deployment module and it is guaranteed by the spec that
it
will deploy on all J2EE 1.4 compliant servers. But if we try to
deploy
it on an J2EE 1.4 compliant app server, that is not at the same
time
Java EE 5 compliant, then our deployment will fail, because of
the
included EJB 3.0 module (which is Java EE 5 spec level).
At the
moment there is an inconsistency in several dialogs in WTP
regarding this
issue. For example the Java EE Module Dependencies
property page of an EAR
1.4 project filters Java EE 5 modules for
selection, while at the same time
the project creation wizard allows a
EJB 3.0 project to be added to an
existing EAR 1.4 project.
I suggest that we discuss this problem and
hope we will have an
agreement for WTP 3.0.1. I invite all application server vendors
represented in this mailing
list to express their support for either
opinion 1 or opinion 2.
Greetings,
Kaloyan Raev
Eclipse WTP
Committer
<http://www.eclipse.org/webtools/people/person.php?name=raev>
Senior Developer
NW C JS TOOLS JEE (BG)
SAP Labs
Bulgaria
T +359/2/9157-416
mailto:kaloyan.raev@xxxxxxx
www.sap.com
P Save
a tree - please do not print this email unless you really need
to!
_______________________________________________
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
_______________________________________________
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
_______________________________________________
wtp-dev
mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
--
Naci Dai - naci.dai@xxxxxxxxxxxxx
eteration a.s.
itu ari-1 25 maslak istanbul tr
ph: +90 212 328 0825 - fax: +90 212 328 0521
_______________________________________________
wtp-dev mailing
list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev