I will throw something else out for this
discussion... The current (1.4-level) EMF-generated classes that ship with WTP
are rather difficult to use for those adopters who are using java 5.0. The
reason is that as soon as you access this api Eclipse floods you with hundreds
of warnings regarding generics safety that you cannot do anything about short
of explicitly suppressing these warnings. The problem with suppressing is that you
loose warnings unrelated to EMF-generated class that you _do_ want to see. The bottom line is that
it would be very beneficial for adopters who are using java 5.0 if WTP
EMF-generated classes were generated using the new EMF 3.0 generics capabilities.
Regarding the “no 5.0 in common rule”,
can we have an honest disclosure of where this requirement is coming from? What
are the use cases? You can’t run WTP with just the common component. If
there are certain adopters that need certain specific plugins to stay at 1.4 so
that they can be re-used in non-WTP contexts, let’s enumerate those
plugins instead of making a sweeping statement. If this is only a hypothetical
requirement, let’s state that too so that everyone knows what we are
dealing with.
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of David M Williams
Sent: Tuesday, October 10, 2006
8:37 AM
To: General discussion of
project-wide or architectural issues.
Subject: Re: [wtp-dev] EMF 3.0
will require Java 5.0
Chuck, which pre-req is that? JEM? XSD? If we
needed a 1.4 version of those, we should say so.
But
the key issue here isn't so much Java 5, or not, but what impact it would have
on adopters code.
If
adopters code doesn't have to change, we're good. If adopters code does have to
change,
we
need to look very closely at this issue and be prepared to use a 1.4 compatible
version.
Oh,
and do I need to say, we'll be looking to your teams Chuck to advise us on
this. :)
We
have stated already that for WTP as a whole we will require Java 5. But,
"common" components
should
stay compatible with 1.4, since those are the ones mostly likely used in other,
smaller
OSGi
environments. Exceptions to this "commons rule" will have to be
approved by the PMC.
But
even for non-common components we will specify an execution environment for
each, to document
and
"enforce" what is required, and then only move up to 1.5 execution
environment if/when there is
some
reason for it for that bundle. That is, no capricious requirement on Java
5 ... there are likely good reasons
to
use it in some plugins and we just want to capture what those reasons are.
Thanks
|
Chuck
Bridgham/Raleigh/IBM@IBMUS
Sent
by: wtp-dev-bounces@xxxxxxxxxxx
10/10/2006 10:16 AM
|
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
|
Ed Merks <merks@xxxxxxxxxx>
|
|
Subject
|
Re: [wtp-dev] EMF 3.0 will require Java 5.0
|
|
Good point Lawrence, it does look that way - I'm assuming EMF codegen can
"generate" both versions, but the prereq plugins now require Java 5.
We'll need to plan accordingly
- Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle
Park, NC
Email: cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
|
Lawrence Mandel <lmandel@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx
10/10/2006 01:43 AM
|
Please
respond to
"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
|
|
|
To
|
wtp-dev@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
|
[wtp-dev] EMF 3.0 will require Java 5.0
|
|
I may have missed any discussion around this but what effect will EMF requiring
Java 5 have on WTP? Will WTP now have to require Java 5?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
----- Forwarded by Lawrence Mandel/Toronto/IBM on 10/10/2006 01:39 AM -----
|
Ed Merks/Toronto/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
10/06/2006 03:16 PM
|
Please
respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
|
To
|
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
emf-dev@xxxxxxxxxxx
|
|
cc
|
|
|
Subject
|
[cross-project-issues-dev] Europa and EMF 3.0
|
|
Hi,
I just wanted to update folks on our progress and what to expect from EMF for
Europa. We are in the process of changing our builds to use Java 5.0 so
all our .class files will only work in a 5.0 JVM. We will update every
single plugin's MANIFEST.MF to indicate that it requires Java 5.0 and we will
increment the version number to 3.0.0. For those downstream clients with
hard coded upper bounds, this will probably cause some pain; you might want to
change the upper bound on your EMF/XSD/SDO dependencies sooner rather than
later.
Bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=79768 contains patches
for a complete templatization of org.eclipse.emf.common. These changes
have been tested and work with no changes to any downstream plugins, so our
first 3.0 build, or one shortly there after, will likely contain these changes;
we're still reviewing them in great detail, so comments and feedback on the
changes there would be most welcome. We'll be particularly sensitive to
any reports of binary incompatibility.
The next step will be templatizing org.eclipse.emf.ecore. Firstly we will
templatize the collection classes in org.eclipse.emf.ecore.util, then the APIs
and implementations in org.eclipse.emf.ecore.resource, and eventually we will
be regenerating the Ecore API itself to exploit all the templatized
collections. One issue I expect will come up is the following. Resource.getContents
will be changed to return EList<EObject>. For clients who have
suppressed EObject from their generated API, this might result in a source
incompatibility, i.e., they'll need to add a cast to EObject when adding their
objects to the resource's contents. The underlying collection has always
been backed by an EObject[] array, so it must already be the case that anything
you add must be compatible with EObject at runtime. This source
incompatibility will only be a problem if you compile your source with Java 5.0
source compatibility and hence you can avoid reacting to this change, or any of
EMF's 3.0 changes, by ensuring you build with 1.4 source compatibility.
If there are any questions, comments, or concerns, now is a good time to raise
them!
Note that in the interest of openness and transparency we will be actively
using the emf-dev mailing list for development discussions like this.
Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265 (t/l 969)
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-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
