From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Marius
Slavescu
Sent: Monday, January 15, 2007 1:00 PM
To: Cross project issues
Cc: TPTP PMC communications (including coordination, announcements, and
Group discussions); eclipse.org-planning-council
Subject: RE: [eclipse.org-planning-council] Re:
[cross-project-issues-dev] Re:EMF usage in TPTP 4.4.0
I've create a
small class that will download all (and only) the manifest.mf files (although
some files might not be Eclipse bundle related, basically only that contains
Bundle-SymbolicName are from Eclipse bundles) from the project drivers' ZIP/JAR
files (I used the latest/M4 SDK drivers or update site archives from all
the projects listed in
http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release projects table).
Some problems
that I encounter while I create the downloadManifestFiles.bat:
- some project don't have download page
- Eclipse platform project doesn't have a direct download link on
the left side
- Monkey project could publish also an update site archive in zip
format.
- Mylar
update site archive is in tgz format, would be better to have a zip file
instead
I don't have
time right now, but I could probably change the included download class to
support update sites directly, although I prefer to use the download zip URLs.
Check also the
REM notes in the downloadManifestFiles.bat script file.
You could
easily change the drivers URLs and rerun the script, make sure you clean up the
folders for which you rerun the download so you don't get manifest files from
previous builds.
Here is the
link to a zip file that includes the set of Europa's manifest files (1207
files) and the script/class used to download them.
http://wiki.eclipse.org/index.php/Image:Europa-manifest-files-20070115.zip
I have not
recreated the previous statistics for this new set of manifest files.
Please let me
know if you have any comments or concerns.
Thanks !
Marius Slavescu
IBM Toronto Laboratory, Canada
Phone: 905-413-3610
|
"Oberhuber,
Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
01/09/2007
05:37 AM
|
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
|
To
|
"eclipse.org-planning-council"
<eclipse.org-planning-council@xxxxxxxxxxx>, "TPTP PMC
communications \(including coordination, announcements,
and Group discussions\)" <tptp-pmc@xxxxxxxxxxx>,
"Cross project issues"
<cross-project-issues-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE:
[eclipse.org-planning-council] Re: [cross-project-issues-dev]
Re:EMF usage in TPTP 4.4.0
|
|
Hello
Marius,
these
statistics are fabulous!
Really interesting how much one can find by just doing a text search.
My
notes below are not directly relevant for the current (EMF) discussion, but I
found it interesting to note:
When
I understand this right, the list of "non-compliant" Manifest.mf
(e.g. that do not specify a manifest version) can be obtained by
- saving the list of file names which contain matches of the
String "Bundle-" into a file,
- sorting it,
- and then comparing against a sorted list of file names when
searching for the string "Bundle-ManifestVersion".
With respect to the
Bundle-RequiredExecutionEnvironment, 10+147+98 = 255 bundles are J2SE-1.[345]
from
the remaining (279-255 =) 24 ones we have 2 in TM:
org.apache.oro
and org.apache.commons.net are both J2SE-1.2
I
wonder what the other 22 might specify.
Since
you seem to have set up a directory with all of Europa extracted already, it
might be helpful if you could save all the Manifest's into an archive for
further investigation:
find
. -name 'manifest.mf' -print > manifest-names.txt && tar cfvz Europa-m4-manifests.tgz
--files-from manifest-names.txt
Actually,
such a "combined archive" of all manifests might be a nice result of
the Europa automated builds in the future...
Cheers,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From:
eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Marius
Slavescu
Sent: Monday, January 08, 2007 5:44 AM
To: TPTP PMC communications (including coordination, announcements,and
Group discussions); Cross project issues; eclipse.org-planning-council
Subject: [eclipse.org-planning-council] Re: [cross-project-issues-dev]
Re:EMF usage in TPTP 4.4.0
I've done a quick investigation of the Europa plugins regarding EMF and
required execution environment.
I've downloaded all the M4 or latest SDK drivers (or update site zips) for the
projects listed in
http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release.
Here are some full text search results in the MANIFEST.MF files from all Europa
plugins (the search strings are on the left side and the plugin count is on the
right side):
Bjorn, regarding your previous comment:
"So as long as you do not regenerate your
models, the code will continue to work on JVM 1.4 without change or reduced
functionality. I also assume, but have not verified, that you could always
re-generate your models using an older EMF and thus
continue to use JVM 1.4 with newer models."
we used EMF 2.2.2 to generate, and we ran the code against EMF 2.3.0 (under
J2SE 1.5) to confirm that the binary compatibility works fine, we didn't find
any problems yet (we covered most of our functions in one day of extensive
testing, we will see if this finding remains true after a full test pass).
The main problem is that EMF 2.3.0 requires J2SE-1.5 at runtime, I haven't
tried yet to remove that requirement and run it on J2SE-1.4 to see if it works
in our scenarios, if it works then I don't understand why they require J2SE-1.5
at runtime.
Based on the large number of plugins that uses EMF (more than 50 direct
dependencies on EMF, and I didn't include XSD which also requires J2SE 1.5) and
the fact that Europa will not provide EMF 2.2.0 I believe a significant part of
Europa functions will not be available on J2SE 1.4 although most of the code could
be compatible with (runnable on) J2SE 1.4.
Although I focused on EMF in this investigation I've seen other plugins that
requires J2SE 1.5, besides Mylar (which probably is not required by anybody, so
no impact on other components) I also found that org.eclipse.gmf.common (by
name looks to be a root plugin in GMF) requires J2SE 1.5, so the J2SE 1.5
requirement might be much larger.
I still think Europa should state more clearly what really works on each target
deployment environment, just saying that (hopefully) most part of it works on
J2SE 1.4 and another (small) part would surface only on J2SE 1.5 might not be
enough for the user to decide how it can be used.
Thanks !
Marius Slavescu
IBM Toronto Laboratory, Canada
Phone: 905-413-3610
|
Jeff
McAffer/Ottawa/IBM@IBMCA
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
01/07/2007
07:33 PM
|
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
|
To
|
Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
cc
|
cross-project-issues-dev-bounces@xxxxxxxxxxx,
tptp-pmc@xxxxxxxxxxx, Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>
|
|
Subject
|
Re:
[cross-project-issues-dev] Re: EMF usage in TPTP 4.4.0
|
|
Bjorn wrote on 01/06/2007 12:52:41 PM:
> TPTP PMC, (cc for FYI to Europa leads)
> While reading the TPTP PMC mailing list, I encountered this statement:
> I think Europa should declare the JRE level that's required to run
> it otherwise most of the components might not work (not sure if they
> can be installed either when Java 1.4 is used).
> One of the requirements for participation in Europa is #8 on the wiki
list:
> 8. All plug-ins must correctly list their required JVM
versions
> in the manifest/plugin.xml.
>
> As I understand it, plug-ins for JVM 5 will not load when a JVM 1.4
> is being used, as long as the manifests are correct. Thus the Europa
> distro will run on both JVM 5 and JVM 1.4 (although perhaps with
> reduced functionality on 1.4 because fewer plug-ins will load). Does
> this solve the issue or am I missing something?
Indeed a bundle declaring an Execution Environment that is not supported at
runtime will not be resolved and will not run. Having each bundle marked
with its *minimum* required execution environment is an important part of
communicating the usability of the bundle to consumers. In a complex
system however there is still a challenge in determining the "real"
minimum. For example, it is likely that the 3.3 Eclipse SDK will ship
with a few plugins marked as requireing Java 5 and Java 6 whereas the vast
majority of the rest of the plugins will be marked as Foundation 1.0 or J2SE
1.4. Our intention is that the SDK work just fine on 1.4 but some of the
additional function requiring Java 5 or 6 just not be available. In this
case the "reduced functionality" is likely quite understandable and
acceptable to end users.
In the larger context of Europa, when some basic infrastructure piece like
EMF (just to pick on Ed) says it needs Java 5, there may be a ripple on that
causes whole swaths of plugins to no longer resolve or function. We don't
currently have any markup or other means of indicating the difference between
these two cases. So people need to look a little more deeply when
considering these scenarios.
Jeff _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
