Home » Modeling » OCL » Eclispe compatibility
| Eclispe compatibility [message #70338] |
Wed, 06 May 2009 12:04  |
Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------000400010600080105090903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I was toying with the latest 1.3 plugins (org.eclipse.ocl and
org.eclipse.ocl.ecore) and was wondering : The code in itself is
compatible with Eclipse 3.4 (haven't tried with Eclipse 3.3), but some
of the listed dependencies have an higher version range. Is it to
prevent installation on Ganymede? Namely :
org.eclipse.ocl.ecore/META-INF/MANIFEST.MF :
org.eclipse.emf.ecore;bundle-version="[2.5.0,2.6.0)";
and
org.eclipse.ocl/META-INF/MANIFEST.MF :
com.ibm.icu.lang;version="[4.0.0,5.0.0)";
com.ibm.icu.text;version="[4.0.0,5.0.0)";
For both "icu" packages, a range starting at 3.8 (haven't tried earlier
versions) would work, and for ecore, ranges starting at 2.4 seem more
likely.
Those are the only things preventing installation and use of OCL 1.3 on
Eclipse ganymede, I believe these version ranges could be softened to
enable Ganymede compatibility. Wonder if we still have time though given
that M7 is out...
Laurent Goubet
Obeo
--------------000400010600080105090903
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr/">Obeo</a>
email;internet:laurent.goubet@obeo.fr
url:http://www.obeo.fr
version:2.1
end:vcard
--------------000400010600080105090903--
|
|
|
| Re: Eclispe compatibility [message #70398 is a reply to message #70338] |
Wed, 06 May 2009 17:15  |
| Eclipse User |
|
|
|
--=-OPpnqAffJVDlyhlAEln8
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hi, Laurent,
The Ecore and UML binding plug-ins declare minor-version dependencies on
their metamodels and keep in locked step with the lower bounds as a
matter of policy. This is because the OCL Ecore and UML binding models
*extend* the Ecore and UML metamodels, thus having dependencies on their
XyzImpl classes (in the UML case, internal API!) which is usually
discouraged. As such, OCL can find that its dependencies make
incompatible changes in the protected API, so this narrow range ensures
that the committer team works to maintain compatibility in every
release.
The ICU dependencies perhaps could have used a 3.8 lower bound, but it
didn't seem necessary as the Ecore and UML bindings require the Galileo
version of the Platform via UML2 and EMF anyway (although, I suppose the
core plug-in could be used independently). However, any new usage of
ICU API that is added to OCL in the future would then have to be tested
on older versions to ensure compatibility. The modeling projects
generally don't have the resources to attend to that. So, bumping the
upper bound of the dependency is usually matched in the lower bound.
HTH,
Christian
On Wed, 2009-05-06 at 18:04 +0200, laurent Goubet wrote:
> Hi,
>
> I was toying with the latest 1.3 plugins (org.eclipse.ocl and
> org.eclipse.ocl.ecore) and was wondering : The code in itself is
> compatible with Eclipse 3.4 (haven't tried with Eclipse 3.3), but some
> of the listed dependencies have an higher version range. Is it to
> prevent installation on Ganymede? Namely :
>
> org.eclipse.ocl.ecore/META-INF/MANIFEST.MF :
> org.eclipse.emf.ecore;bundle-version="[2.5.0,2.6.0)";
>
> and
> org.eclipse.ocl/META-INF/MANIFEST.MF :
> com.ibm.icu.lang;version="[4.0.0,5.0.0)";
> com.ibm.icu.text;version="[4.0.0,5.0.0)";
>
> For both "icu" packages, a range starting at 3.8 (haven't tried earlier
> versions) would work, and for ecore, ranges starting at 2.4 seem more
> likely.
>
> Those are the only things preventing installation and use of OCL 1.3 on
> Eclipse ganymede, I believe these version ranges could be softened to
> enable Ganymede compatibility. Wonder if we still have time though given
> that M7 is out...
>
> Laurent Goubet
> Obeo
--=-OPpnqAffJVDlyhlAEln8
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Laurent,<BR>
<BR>
The Ecore and UML binding plug-ins declare minor-version dependencies on their metamodels and keep in locked step with the lower bounds as a matter of policy. This is because the OCL Ecore and UML binding models *extend* the Ecore and UML metamodels, thus having dependencies on their XyzImpl classes (in the UML case, internal API!) which is usually discouraged. As such, OCL can find that its dependencies make incompatible changes in the protected API, so this narrow range ensures that the committer team works to maintain compatibility in every release.<BR>
<BR>
The ICU dependencies perhaps could have used a 3.8 lower bound, but it didn't seem necessary as the Ecore and UML bindings require the Galileo version of the Platform via UML2 and EMF anyway (although, I suppose the core plug-in could be used independently). However, any new usage of ICU API that is added to OCL in the future would then have to be tested on older versions to ensure compatibility. The modeling projects generally don't have the resources to attend to that. So, bumping the upper bound of the dependency is usually matched in the lower bound.<BR>
<BR>
HTH,<BR>
<BR>
Christian<BR>
<BR>
On Wed, 2009-05-06 at 18:04 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi,
I was toying with the latest 1.3 plugins (org.eclipse.ocl and
org.eclipse.ocl.ecore) and was wondering : The code in itself is
compatible with Eclipse 3.4 (haven't tried with Eclipse 3.3), but some
of the listed dependencies have an higher version range. Is it to
prevent installation on Ganymede? Namely :
org.eclipse.ocl.ecore/META-INF/MANIFEST.MF :
org.eclipse.emf.ecore;bundle-version="[2.5.0,2.6.0) ";
and
org.eclipse.ocl/META-INF/MANIFEST.MF :
com.ibm.icu.lang;version="[4.0.0,5.0.0)";
com.ibm.icu.text;version="[4.0.0,5.0.0)";
For both "icu" packages, a range starting at 3.8 (haven't tried earlier
versions) would work, and for ecore, ranges starting at 2.4 seem more
likely.
Those are the only things preventing installation and use of OCL 1.3 on
Eclipse ganymede, I believe these version ranges could be softened to
enable Ganymede compatibility. Wonder if we still have time though given
that M7 is out...
Laurent Goubet
Obeo
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-OPpnqAffJVDlyhlAEln8--
|
|
|
| Re: Eclispe compatibility [message #70457 is a reply to message #70398] |
Thu, 07 May 2009 05:29 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------080201040700050209080901
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Hi Christian,
That's a shame knowing the improvements of OCL1.3 cannot be leveraged
within Eclipse 3.4 because of these narrow version ranges. The OCL 1.3
download page clearly indicates that its dependencies are Eclipse 3.5,
yet it would have been nice if the installation at least worked on
Eclipse 3.4. That sure doesn't compel the development team to ensure
compatibility for 3.4 (as per the download page's dependency listing),
but having it provided is a nice bonus (even more so knowing that the
code itself is compatible with ganymede, but only version ranges aren't.
Laurent Goubet
Obeo
Christian W. Damus a écrit :
> Hi, Laurent,
>
> The Ecore and UML binding plug-ins declare minor-version dependencies on
> their metamodels and keep in locked step with the lower bounds as a
> matter of policy. This is because the OCL Ecore and UML binding models
> *extend* the Ecore and UML metamodels, thus having dependencies on their
> XyzImpl classes (in the UML case, internal API!) which is usually
> discouraged. As such, OCL can find that its dependencies make
> incompatible changes in the protected API, so this narrow range ensures
> that the committer team works to maintain compatibility in every release.
>
> The ICU dependencies perhaps could have used a 3.8 lower bound, but it
> didn't seem necessary as the Ecore and UML bindings require the Galileo
> version of the Platform via UML2 and EMF anyway (although, I suppose the
> core plug-in could be used independently). However, any new usage of
> ICU API that is added to OCL in the future would then have to be tested
> on older versions to ensure compatibility. The modeling projects
> generally don't have the resources to attend to that. So, bumping the
> upper bound of the dependency is usually matched in the lower bound.
>
> HTH,
>
> Christian
>
> On Wed, 2009-05-06 at 18:04 +0200, laurent Goubet wrote:
>> Hi,
>>
>> I was toying with the latest 1.3 plugins (org.eclipse.ocl and
>> org.eclipse.ocl.ecore) and was wondering : The code in itself is
>> compatible with Eclipse 3.4 (haven't tried with Eclipse 3.3), but some
>> of the listed dependencies have an higher version range. Is it to
>> prevent installation on Ganymede? Namely :
>>
>> org.eclipse.ocl.ecore/META-INF/MANIFEST.MF :
>> org.eclipse.emf.ecore;bundle-version="[2.5.0,2.6.0)";
>>
>> and
>> org.eclipse.ocl/META-INF/MANIFEST.MF :
>> com.ibm.icu.lang;version="[4.0.0,5.0.0)";
>> com.ibm.icu.text;version="[4.0.0,5.0.0)";
>>
>> For both "icu" packages, a range starting at 3.8 (haven't tried earlier
>> versions) would work, and for ecore, ranges starting at 2.4 seem more
>> likely.
>>
>> Those are the only things preventing installation and use of OCL 1.3 on
>> Eclipse ganymede, I believe these version ranges could be softened to
>> enable Ganymede compatibility. Wonder if we still have time though given
>> that M7 is out...
>>
>> Laurent Goubet
>> Obeo
--------------080201040700050209080901
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"
YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyLyI+T2JlbzwvYT4NCmVtYWls O2ludGVybmV0
OmxhdXJlbnQuZ291YmV0QG9iZW8uZnINCnVybDpodHRwOi8vd3d3Lm9iZW8u ZnINCnZlcnNp
b246Mi4xDQplbmQ6dmNhcmQNCg0K
--------------080201040700050209080901--
|
|
|
| Re: Eclispe compatibility [message #70540 is a reply to message #70457] |
Thu, 07 May 2009 09:01 |
| Eclipse User |
|
|
|
--=-gT8QEsfWRCq8fH8nrfyb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi, Laurent,
If you're interested in helping the new OCL team to support a wider
range of dependencies, they may very well be interested. Just be
careful not to use any newer features of EMF and UML2. But, any
incompatible changes in the protected API of Ecore or UML2 could easily
eighty-six the effort anyway. It very nearly happened in this release
with Ecore, and UML2 actually incremented their major version because of
API breakage. In that case, users of OCL together with UML2 can't use
Ganymede, anyway.
Cheers,
Christian
On Thu, 2009-05-07 at 11:29 +0200, laurent Goubet wrote:
> Hi Christian,
>=20
> That's a shame knowing the improvements of OCL1.3 cannot be leveraged=20
> within Eclipse 3.4 because of these narrow version ranges. The OCL 1.3=20
> download page clearly indicates that its dependencies are Eclipse 3.5,=20
> yet it would have been nice if the installation at least worked on=20
> Eclipse 3.4. That sure doesn't compel the development team to ensure=20
> compatibility for 3.4 (as per the download page's dependency listing),=20
> but having it provided is a nice bonus (even more so knowing that the=20
> code itself is compatible with ganymede, but only version ranges aren't.
>=20
> Laurent Goubet
> Obeo
>=20
> Christian W. Damus a =C3=A9crit :
> > Hi, Laurent,
> >=20
> > The Ecore and UML binding plug-ins declare minor-version dependencies o=
n=20
> > their metamodels and keep in locked step with the lower bounds as a=20
> > matter of policy. This is because the OCL Ecore and UML binding models=
=20
> > *extend* the Ecore and UML metamodels, thus having dependencies on thei=
r=20
> > XyzImpl classes (in the UML case, internal API!) which is usually=20
> > discouraged. As such, OCL can find that its dependencies make=20
> > incompatible changes in the protected API, so this narrow range ensures=
=20
> > that the committer team works to maintain compatibility in every releas=
e.
> >=20
> > The ICU dependencies perhaps could have used a 3.8 lower bound, but it=20
> > didn't seem necessary as the Ecore and UML bindings require the Galileo=
=20
> > version of the Platform via UML2 and EMF anyway (although, I suppose th=
e=20
> > core plug-in could be used independently). However, any new usage of=20
> > ICU API that is added to OCL in the future would then have to be tested=
=20
> > on older versions to ensure compatibility. The modeling projects=20
> > generally don't have the resources to attend to that. So, bumping the=20
> > upper bound of the dependency is usually matched in the lower bound.
> >=20
> > HTH,
> >=20
> > Christian
> >=20
> > On Wed, 2009-05-06 at 18:04 +0200, laurent Goubet wrote:
> >> Hi,
> >>
> >> I was toying with the latest 1.3 plugins (org.eclipse.ocl and=20
> >> org.eclipse.ocl.ecore) and was wondering : The code in itself is=20
> >> compatible with Eclipse 3.4 (haven't tried with Eclipse 3.3), but some=
=20
> >> of the listed dependencies have an higher version range. Is it to=20
> >> prevent installation on Ganymede? Namely :
> >>
> >> org.eclipse.ocl.ecore/META-INF/MANIFEST.MF :
> >> org.eclipse.emf.ecore;bundle-version=3D"[2.5.0,2.6.0)";
> >>
> >> and
> >> org.eclipse.ocl/META-INF/MANIFEST.MF :
> >> com.ibm.icu.lang;version=3D"[4.0.0,5.0.0)";
> >> com.ibm.icu.text;version=3D"[4.0.0,5.0.0)";
> >>
> >> For both "icu" packages, a range starting at 3.8 (haven't tried earlie=
r=20
> >> versions) would work, and for ecore, ranges starting at 2.4 seem more=20
> >> likely.
> >>
> >> Those are the only things preventing installation and use of OCL 1.3 o=
n=20
> >> Eclipse ganymede, I believe these version ranges could be softened to=20
> >> enable Ganymede compatibility. Wonder if we still have time though giv=
en=20
> >> that M7 is out...
> >>
> >> Laurent Goubet
> >> Obeo
>=20
--=-gT8QEsfWRCq8fH8nrfyb
Content-Type: text/html; charset="utf-8"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.1.1">
</HEAD>
<BODY>
Hi, Laurent,<BR>
<BR>
If you're interested in helping the new OCL team to support a wider range of dependencies, they may very well be interested. Just be careful not to use any newer features of EMF and UML2. But, any incompatible changes in the protected API of Ecore or UML2 could easily eighty-six the effort anyway. It very nearly happened in this release with Ecore, and UML2 actually incremented their major version because of API breakage. In that case, users of OCL together with UML2 can't use Ganymede, anyway.<BR>
<BR>
Cheers,<BR>
<BR>
Christian<BR>
<BR>
On Thu, 2009-05-07 at 11:29 +0200, laurent Goubet wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,
That's a shame knowing the improvements of OCL1.3 cannot be leveraged
within Eclipse 3.4 because of these narrow version ranges. The OCL 1.3
download page clearly indicates that its dependencies are Eclipse 3.5,
yet it would have been nice if the installation at least worked on
Eclipse 3.4. That sure doesn't compel the development team to ensure
compatibility for 3.4 (as per the download page's dependency listing),
but having it provided is a nice bonus (even more so knowing that the
code itself is compatible with ganymede, but only version ranges aren't.
Laurent Goubet
Obeo
Christian W. Damus a écrit :
> Hi, Laurent,
>
> The Ecore and UML binding plug-ins declare minor-version dependencies on
> their metamodels and keep in locked step with the lower bounds as a
> matter of policy. This is because the OCL Ecore and UML binding models
> *extend* the Ecore and UML metamodels, thus having dependencies on their
> XyzImpl classes (in the UML case, internal API!) which is usually
> discouraged. As such, OCL can find that its dependencies make
> incompatible changes in the protected API, so this narrow range ensures
> that the committer team works to maintain compatibility in every release.
>
> The ICU dependencies perhaps could have used a 3.8 lower bound, but it
> didn't seem necessary as the Ecore and UML bindings require the Galileo
> version of the Platform via UML2 and EMF anyway (although, I suppose the
> core plug-in could be used independently). However, any new usage of
> ICU API that is added to OCL in the future would then have to be tested
> on older versions to ensure compatibility. The modeling projects
> generally don't have the resources to attend to that. So, bumping the
> upper bound of the dependency is usually matched in the lower bound.
>
> HTH,
>
> Christian
>
> On Wed, 2009-05-06 at 18:04 +0200, laurent Goubet wrote:
>> Hi,
>>
>> I was toying with the latest 1.3 plugins (org.eclipse.ocl and
>> org.eclipse.ocl.ecore) and was wondering : The code in itself is
>> compatible with Eclipse 3.4 (haven't tried with Eclipse 3.3), but some
>> of the listed dependencies have an higher version range. Is it to
>> prevent installation on Ganymede? Namely :
>>
>> org.eclipse.ocl.ecore/META-INF/MANIFEST.MF :
>> org.eclipse.emf.ecore;bundle-version="[2.5.0,2.6.0) ";
>>
>> and
>> org.eclipse.ocl/META-INF/MANIFEST.MF :
>> com.ibm.icu.lang;version="[4.0.0,5.0.0)";
>> com.ibm.icu.text;version="[4.0.0,5.0.0)";
>>
>> For both "icu" packages, a range starting at 3.8 (haven't tried earlier
>> versions) would work, and for ecore, ranges starting at 2.4 seem more
>> likely.
>>
>> Those are the only things preventing installation and use of OCL 1.3 on
>> Eclipse ganymede, I believe these version ranges could be softened to
>> enable Ganymede compatibility. Wonder if we still have time though given
>> that M7 is out...
>>
>> Laurent Goubet
>> Obeo
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-gT8QEsfWRCq8fH8nrfyb--
|
|
|
| Re: Eclispe compatibility [message #71390 is a reply to message #70338] |
Wed, 10 June 2009 10:47 |
| Eclipse User |
|
|
|
Hi Laurent
It is difficult to preserve backward Ecore compatibility for OCL 1.3.0
because Ecore does not preserve backward source compatibility through
the introduction of MinimalEObjectImpl; at least one feature has changed
from a protected variable accessed by genmodelled code to an accessor.
Regards
Ed Willink
laurent Goubet wrote:
> Hi,
>
> I was toying with the latest 1.3 plugins (org.eclipse.ocl and
> org.eclipse.ocl.ecore) and was wondering : The code in itself is
> compatible with Eclipse 3.4 (haven't tried with Eclipse 3.3), but some
> of the listed dependencies have an higher version range. Is it to
> prevent installation on Ganymede? Namely :
>
> org.eclipse.ocl.ecore/META-INF/MANIFEST.MF :
> org.eclipse.emf.ecore;bundle-version="[2.5.0,2.6.0)";
>
> and
> org.eclipse.ocl/META-INF/MANIFEST.MF :
> com.ibm.icu.lang;version="[4.0.0,5.0.0)";
> com.ibm.icu.text;version="[4.0.0,5.0.0)";
>
> For both "icu" packages, a range starting at 3.8 (haven't tried earlier
> versions) would work, and for ecore, ranges starting at 2.4 seem more
> likely.
>
> Those are the only things preventing installation and use of OCL 1.3 on
> Eclipse ganymede, I believe these version ranges could be softened to
> enable Ganymede compatibility. Wonder if we still have time though given
> that M7 is out...
>
> Laurent Goubet
> Obeo
|
|
|
Goto Forum:
Current Time: Thu Oct 30 03:03:25 EDT 2025
Powered by FUDForum. Page generated in 0.04795 seconds |
Home