Home » Modeling » EMF » [CDO] CDO4 depends on which EMF version?
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657304 is a reply to message #657291] |
Wed, 02 March 2011 11:09   |
 Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Gergely,
we just regenerated our models a few days ago, and apparently
org.eclipse.emf.ecore.util.Switch concept was recently introduced in
EMF. Our goals is trying to stay as much compatible as possible, but
probably the minimum version should be 2.6.0, as CDO relies on some new
features of EMF to implement the Legacy Model Support.
So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
compatible. I'll recommend you to switch to the revision before that
change was introduced (which I believe happened 2 days ago).
We'll post here some feedback as soon as we know how to deal with the
Switch thing ;)
Cheers,
Víctor.
Gergely Nagy escribió:
> I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors, for
> example in org.eclipse.emf.cdo EresourceSwitch is missing
> org.eclipse.emf.ecore.util.Switch.
>
> The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0). Shouldn't
> this be [2.7.0...?
>
> Does this actually mean that CDO 4.0 will require EMF 2.7 when released?
>
> Greg
>
|
|
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657317 is a reply to message #657304] |
Wed, 02 March 2011 12:30 |
Gábor Nagy
Messages: 9
Registered: July 2009
Location: Budapest, Hungary |
Junior Member |
|
|
Thanks Victor!
I'm trying to test a feature introduced yesterday, so I guess I'll try to upgrade to 2.7 in my development environment. It is good to know that compatibility will remain with 2.6 though, as that is what our product is currently based on. In any case, the manifests will need to be updated from 2.4, shall I file a bug about this?
Greg
| Victor Roldan Betancort wrote on Wed, 02 March 2011 12:09 | Gergely,
we just regenerated our models a few days ago, and apparently
org.eclipse.emf.ecore.util.Switch concept was recently introduced in
EMF. Our goals is trying to stay as much compatible as possible, but
probably the minimum version should be 2.6.0, as CDO relies on some new
features of EMF to implement the Legacy Model Support.
So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
compatible. I'll recommend you to switch to the revision before that
change was introduced (which I believe happened 2 days ago).
We'll post here some feedback as soon as we know how to deal with the
Switch thing 
Cheers,
Víctor.
Gergely Nagy escribió:
> I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors, for
> example in org.eclipse.emf.cdo EresourceSwitch is missing
> org.eclipse.emf.ecore.util.Switch.
>
> The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0). Shouldn't
> this be [2.7.0...?
>
> Does this actually mean that CDO 4.0 will require EMF 2.7 when released?
>
> Greg
>
|
|
|
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657323 is a reply to message #657317] |
Wed, 02 March 2011 12:49 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Gergely,
Gergely Nagy escribió:
> Thanks Victor!
you are welcome!
> I'm trying to test a feature introduced yesterday, so I guess I'll try
> to upgrade to 2.7 in my development environment. It is good to know that
> compatibility will remain with 2.6 though, as that is what our product
> is currently based on.
I assume at this point of the development is very unlikely that
dependencies with 2.7.0 would be introduced. We (Open Canarias) also
rely on 2.6.0, so we are very interested this compatibility to be kept.
> In any case, the manifests will need to be
> updated from 2.4, shall I file a bug about this?
I really haven't tested if CDO 4.0 is compatible with < 2.6.x, but
chances are it won't (as I said previously, EMF mechanisms to make
Legacy Support feasible are a good example). Maybe the others could
confirm this.
So yes, please submit that bug, it shall serve us at least as a
reminder! Please make clear in the zilla evidences are necessary for the
version range to be narrowed.
Cheers!
> Victor Roldan Betancort wrote on Wed, 02 March 2011 12:09
>> Gergely,
>>
>> we just regenerated our models a few days ago, and apparently
>> org.eclipse.emf.ecore.util.Switch concept was recently introduced in
>> EMF. Our goals is trying to stay as much compatible as possible, but
>> probably the minimum version should be 2.6.0, as CDO relies on some
>> new features of EMF to implement the Legacy Model Support.
>>
>> So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
>> compatible. I'll recommend you to switch to the revision before that
>> change was introduced (which I believe happened 2 days ago).
>>
>> We'll post here some feedback as soon as we know how to deal with the
>> Switch thing ;)
>>
>> Cheers,
>> Víctor.
>>
>> Gergely Nagy escribió:
>> > I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors,
>> for
>> > example in org.eclipse.emf.cdo EresourceSwitch is missing
>> > org.eclipse.emf.ecore.util.Switch.
>> >
>> > The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0). Shouldn't
>> > this be [2.7.0...?
>> >
>> > Does this actually mean that CDO 4.0 will require EMF 2.7 when
>> released?
>> >
>> > Greg
>> >
>
>
|
|
| | | |
| Re: [CDO] CDO4 depends on which EMF version? [message #657353 is a reply to message #657341] |
Wed, 02 March 2011 14:14 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Great, thanks Eike :D
Eike Stepper escribió:
> Am 02.03.2011 14:22, schrieb Eike Stepper:
>> Perhaps we can influence that with the "Runtime Version" property in
>> the GenModel...
> Yes, that helped. I've committed the change in the context of bug 338508.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>> Am 02.03.2011 14:16, schrieb Eike Stepper:
>>> Guys,
>>>
>>> This breaking change in EMF was entirely new to me and I even did not
>>> realize it when it happened.
>>>
>>> I'm not sure how to deal with this as we can certainly not stop to
>>> regenerate our internal models in response to evolution of our models
>>> or of EMF itself.
>>>
>>> The best solution would be if we could switch off this new switch
>>> (how ironic!). Ed, what do you think?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>>
>>> Am 02.03.2011 11:55, schrieb Gergely Nagy:
>>>> I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors,
>>>> for example in org.eclipse.emf.cdo EresourceSwitch is missing
>>>> org.eclipse.emf.ecore.util.Switch.
>>>>
>>>> The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0).
>>>> Shouldn't this be [2.7.0...?
>>>>
>>>> Does this actually mean that CDO 4.0 will require EMF 2.7 when
>>>> released?
>>>>
>>>> Greg
>>>>
|
|
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657392 is a reply to message #657323] |
Wed, 02 March 2011 15:48 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------010904080803080503090407
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Víctor,
<rant>
Your comment
I really haven't tested if CDO 4.0 is compatible with < 2.6.x
is one of the things that bugs me most about all these "hard coded"
version ranges in the source repository. The lower bound is set once
and then it's not updated again, nor (worst of all) is it ever tested to
check if it's valid. So lower bounds degrade into bogusness quickly
from release to release. The upper bound, on the other hand, is an
assertion that "I expect to stop working at some point." It's
completely baseless forecasting of the future; about as accurate as
Vancouver weather forecasting. Should the version ever change to exceed
the asserted upper bound, the first thing you need to do is sweeping
updates of the upper bounds to even try it out (to even run tests),
which generally turns out to reveal all is working fine.
</rant>
Víctor Roldán Betancort wrote:
> Gergely,
>
> Gergely Nagy escribió:
>> Thanks Victor!
>
> you are welcome!
>
>> I'm trying to test a feature introduced yesterday, so I guess I'll try
>> to upgrade to 2.7 in my development environment. It is good to know that
>> compatibility will remain with 2.6 though, as that is what our product
>> is currently based on.
>
> I assume at this point of the development is very unlikely that
> dependencies with 2.7.0 would be introduced. We (Open Canarias) also
> rely on 2.6.0, so we are very interested this compatibility to be kept.
>
>> In any case, the manifests will need to be
>> updated from 2.4, shall I file a bug about this?
>
> I really haven't tested if CDO 4.0 is compatible with < 2.6.x, but
> chances are it won't (as I said previously, EMF mechanisms to make
> Legacy Support feasible are a good example). Maybe the others could
> confirm this.
>
> So yes, please submit that bug, it shall serve us at least as a
> reminder! Please make clear in the zilla evidences are necessary for
> the version range to be narrowed.
>
> Cheers!
>
>> Victor Roldan Betancort wrote on Wed, 02 March 2011 12:09
>>> Gergely,
>>>
>>> we just regenerated our models a few days ago, and apparently
>>> org.eclipse.emf.ecore.util.Switch concept was recently introduced in
>>> EMF. Our goals is trying to stay as much compatible as possible, but
>>> probably the minimum version should be 2.6.0, as CDO relies on some
>>> new features of EMF to implement the Legacy Model Support.
>>>
>>> So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
>>> compatible. I'll recommend you to switch to the revision before that
>>> change was introduced (which I believe happened 2 days ago).
>>>
>>> We'll post here some feedback as soon as we know how to deal with the
>>> Switch thing ;)
>>>
>>> Cheers,
>>> Víctor.
>>>
>>> Gergely Nagy escribió:
>>> > I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors,
>>> for
>>> > example in org.eclipse.emf.cdo EresourceSwitch is missing
>>> > org.eclipse.emf.ecore.util.Switch.
>>> >
>>> > The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0).
>>> Shouldn't
>>> > this be [2.7.0...?
>>> >
>>> > Does this actually mean that CDO 4.0 will require EMF 2.7 when
>>> released?
>>> >
>>> > Greg
>>> >
>>
>>
>
--------------010904080803080503090407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Víctor,<br>
<br>
<rant><br>
<br>
Your comment<br>
<blockquote>I really haven't tested if CDO 4.0 is compatible with <
2.6.x<br>
</blockquote>
is one of the things that bugs me most about all these "hard coded"
version ranges in the source repository. The lower bound is set once
and then it's not updated again, nor (worst of all) is it ever tested
to check if it's valid. So lower bounds degrade into bogusness quickly
from release to release. The upper bound, on the other hand, is an
assertion that "I expect to stop working at some point." It's
completely baseless forecasting of the future; about as accurate as
Vancouver weather forecasting. Should the version ever change to
exceed the asserted upper bound, the first thing you need to do is
sweeping updates of the upper bounds to even try it out (to even run
tests), which generally turns out to reveal all is working fine.<br>
<br>
</rant><br>
<br>
<br>
Víctor Roldán Betancort wrote:
<blockquote cite="mid:ikle10$1qj$1@news.eclipse.org" type="cite">Gergely,
<br>
<br>
Gergely Nagy escribió:
<br>
<blockquote type="cite">Thanks Victor!
<br>
</blockquote>
<br>
you are welcome!
<br>
<br>
<blockquote type="cite">I'm trying to test a feature introduced
yesterday, so I guess I'll try
<br>
to upgrade to 2.7 in my development environment. It is good to know
that
<br>
compatibility will remain with 2.6 though, as that is what our product
<br>
is currently based on.
<br>
</blockquote>
<br>
I assume at this point of the development is very unlikely that
dependencies with 2.7.0 would be introduced. We (Open Canarias) also
rely on 2.6.0, so we are very interested this compatibility to be kept.
<br>
<br>
<blockquote type="cite">In any case, the manifests will need to be
<br>
updated from 2.4, shall I file a bug about this?
<br>
</blockquote>
<br>
I really haven't tested if CDO 4.0 is compatible with < 2.6.x, but
chances are it won't (as I said previously, EMF mechanisms to make
Legacy Support feasible are a good example). Maybe the others could
confirm this.
<br>
<br>
So yes, please submit that bug, it shall serve us at least as a
reminder! Please make clear in the zilla evidences are necessary for
the version range to be narrowed.
<br>
<br>
Cheers!
<br>
<br>
<blockquote type="cite">Victor Roldan Betancort wrote on Wed, 02
March 2011 12:09
<br>
<blockquote type="cite">Gergely,
<br>
<br>
we just regenerated our models a few days ago, and apparently
<br>
org.eclipse.emf.ecore.util.Switch concept was recently introduced in
<br>
EMF. Our goals is trying to stay as much compatible as possible, but
<br>
probably the minimum version should be 2.6.0, as CDO relies on some
<br>
new features of EMF to implement the Legacy Model Support.
<br>
<br>
So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
<br>
compatible. I'll recommend you to switch to the revision before that
<br>
change was introduced (which I believe happened 2 days ago).
<br>
<br>
We'll post here some feedback as soon as we know how to deal with the
<br>
Switch thing ;)
<br>
<br>
Cheers,
<br>
Víctor.
<br>
<br>
Gergely Nagy escribió:
<br>
> I'm trying to run CDO HEAD from SVN. I'm seeing some compile
errors,
<br>
for
<br>
> example in org.eclipse.emf.cdo EresourceSwitch is missing
<br>
> org.eclipse.emf.ecore.util.Switch.
<br>
>
<br>
> The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0).
Shouldn't
<br>
> this be [2.7.0...?
<br>
>
<br>
> Does this actually mean that CDO 4.0 will require EMF 2.7 when
<br>
released?
<br>
>
<br>
> Greg
<br>
>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>
--------------010904080803080503090407--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657399 is a reply to message #657392] |
Wed, 02 March 2011 16:36 |
|
I do agree to some extent. Vik, would you like to volunteer for the creation of new Hudson jobs downstream to our integration job. These jobs should take what's been built, deploy it into the older targets that we claim to be compatible with and run the tests. Adolfo seems to become a Buckminster expert, he might be helpful ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 02.03.2011 16:48, schrieb Ed Merks:
> Víctor,
>
> <rant>
>
> Your comment
>
> I really haven't tested if CDO 4.0 is compatible with < 2.6.x
>
> is one of the things that bugs me most about all these "hard coded" version ranges in the source repository. The lower bound is set once and then it's not updated again, nor (worst of all) is it ever tested to check if it's valid. So lower bounds degrade into bogusness quickly from release to release. The upper bound, on the other hand, is an assertion that "I expect to stop working at some point." It's completely baseless forecasting of the future; about as accurate as Vancouver weather forecasting. Should the version ever change to exceed the asserted upper bound, the first thing you need to do is sweeping updates of the upper bounds to even try it out (to even run tests), which generally turns out to reveal all is working fine.
>
> </rant>
>
>
> Víctor Roldán Betancort wrote:
>> Gergely,
>>
>> Gergely Nagy escribió:
>>> Thanks Victor!
>>
>> you are welcome!
>>
>>> I'm trying to test a feature introduced yesterday, so I guess I'll try
>>> to upgrade to 2.7 in my development environment. It is good to know that
>>> compatibility will remain with 2.6 though, as that is what our product
>>> is currently based on.
>>
>> I assume at this point of the development is very unlikely that dependencies with 2.7.0 would be introduced. We (Open Canarias) also rely on 2.6.0, so we are very interested this compatibility to be kept.
>>
>>> In any case, the manifests will need to be
>>> updated from 2.4, shall I file a bug about this?
>>
>> I really haven't tested if CDO 4.0 is compatible with < 2.6.x, but chances are it won't (as I said previously, EMF mechanisms to make Legacy Support feasible are a good example). Maybe the others could confirm this.
>>
>> So yes, please submit that bug, it shall serve us at least as a reminder! Please make clear in the zilla evidences are necessary for the version range to be narrowed.
>>
>> Cheers!
>>
>>> Victor Roldan Betancort wrote on Wed, 02 March 2011 12:09
>>>> Gergely,
>>>>
>>>> we just regenerated our models a few days ago, and apparently
>>>> org.eclipse.emf.ecore.util.Switch concept was recently introduced in
>>>> EMF. Our goals is trying to stay as much compatible as possible, but
>>>> probably the minimum version should be 2.6.0, as CDO relies on some
>>>> new features of EMF to implement the Legacy Model Support.
>>>>
>>>> So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
>>>> compatible. I'll recommend you to switch to the revision before that
>>>> change was introduced (which I believe happened 2 days ago).
>>>>
>>>> We'll post here some feedback as soon as we know how to deal with the
>>>> Switch thing ;)
>>>>
>>>> Cheers,
>>>> Víctor.
>>>>
>>>> Gergely Nagy escribió:
>>>> > I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors,
>>>> for
>>>> > example in org.eclipse.emf.cdo EresourceSwitch is missing
>>>> > org.eclipse.emf.ecore.util.Switch.
>>>> >
>>>> > The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0). Shouldn't
>>>> > this be [2.7.0...?
>>>> >
>>>> > Does this actually mean that CDO 4.0 will require EMF 2.7 when
>>>> released?
>>>> >
>>>> > Greg
>>>> >
>>>
>>>
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657716 is a reply to message #657392] |
Thu, 03 March 2011 17:10 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
Ed,
I can only agree with your comments. Its something we should take better
care of! We shall set some mechanisms to systematically test version
range compatibility. As Eike suggest, a Hudson build with properly
selected bundle versions should help. Can you think on any way to test
this in our Eclipse development environments, besides switching target
platform?
Cheers.
Ed Merks escribió:
> Víctor,
>
> <rant>
>
> Your comment
>
> I really haven't tested if CDO 4.0 is compatible with < 2.6.x
>
> is one of the things that bugs me most about all these "hard coded"
> version ranges in the source repository. The lower bound is set once
> and then it's not updated again, nor (worst of all) is it ever tested to
> check if it's valid. So lower bounds degrade into bogusness quickly
> from release to release. The upper bound, on the other hand, is an
> assertion that "I expect to stop working at some point." It's
> completely baseless forecasting of the future; about as accurate as
> Vancouver weather forecasting. Should the version ever change to exceed
> the asserted upper bound, the first thing you need to do is sweeping
> updates of the upper bounds to even try it out (to even run tests),
> which generally turns out to reveal all is working fine.
>
> </rant>
>
>
> Víctor Roldán Betancort wrote:
>> Gergely,
>>
>> Gergely Nagy escribió:
>>> Thanks Victor!
>>
>> you are welcome!
>>
>>> I'm trying to test a feature introduced yesterday, so I guess I'll try
>>> to upgrade to 2.7 in my development environment. It is good to know that
>>> compatibility will remain with 2.6 though, as that is what our product
>>> is currently based on.
>>
>> I assume at this point of the development is very unlikely that
>> dependencies with 2.7.0 would be introduced. We (Open Canarias) also
>> rely on 2.6.0, so we are very interested this compatibility to be kept.
>>
>>> In any case, the manifests will need to be
>>> updated from 2.4, shall I file a bug about this?
>>
>> I really haven't tested if CDO 4.0 is compatible with < 2.6.x, but
>> chances are it won't (as I said previously, EMF mechanisms to make
>> Legacy Support feasible are a good example). Maybe the others could
>> confirm this.
>>
>> So yes, please submit that bug, it shall serve us at least as a
>> reminder! Please make clear in the zilla evidences are necessary for
>> the version range to be narrowed.
>>
>> Cheers!
>>
>>> Victor Roldan Betancort wrote on Wed, 02 March 2011 12:09
>>>> Gergely,
>>>>
>>>> we just regenerated our models a few days ago, and apparently
>>>> org.eclipse.emf.ecore.util.Switch concept was recently introduced in
>>>> EMF. Our goals is trying to stay as much compatible as possible, but
>>>> probably the minimum version should be 2.6.0, as CDO relies on some
>>>> new features of EMF to implement the Legacy Model Support.
>>>>
>>>> So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
>>>> compatible. I'll recommend you to switch to the revision before that
>>>> change was introduced (which I believe happened 2 days ago).
>>>>
>>>> We'll post here some feedback as soon as we know how to deal with the
>>>> Switch thing ;)
>>>>
>>>> Cheers,
>>>> Víctor.
>>>>
>>>> Gergely Nagy escribió:
>>>> > I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors,
>>>> for
>>>> > example in org.eclipse.emf.cdo EresourceSwitch is missing
>>>> > org.eclipse.emf.ecore.util.Switch.
>>>> >
>>>> > The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0).
>>>> Shouldn't
>>>> > this be [2.7.0...?
>>>> >
>>>> > Does this actually mean that CDO 4.0 will require EMF 2.7 when
>>>> released?
>>>> >
>>>> > Greg
>>>> >
>>>
>>>
>>
|
|
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657719 is a reply to message #657399] |
Thu, 03 March 2011 17:26 |
Victor Roldan Betancort
Messages: 524
Registered: July 2009 |
Senior Member |
|
|
I'll look for some time for it!
Eike Stepper escribió:
> I do agree to some extent. Vik, would you like to volunteer for the
> creation of new Hudson jobs downstream to our integration job. These
> jobs should take what's been built, deploy it into the older targets
> that we claim to be compatible with and run the tests. Adolfo seems to
> become a Buckminster expert, he might be helpful ;-)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> Am 02.03.2011 16:48, schrieb Ed Merks:
>> Víctor,
>>
>> <rant>
>>
>> Your comment
>>
>> I really haven't tested if CDO 4.0 is compatible with < 2.6.x
>>
>> is one of the things that bugs me most about all these "hard coded"
>> version ranges in the source repository. The lower bound is set once
>> and then it's not updated again, nor (worst of all) is it ever tested
>> to check if it's valid. So lower bounds degrade into bogusness quickly
>> from release to release. The upper bound, on the other hand, is an
>> assertion that "I expect to stop working at some point." It's
>> completely baseless forecasting of the future; about as accurate as
>> Vancouver weather forecasting. Should the version ever change to
>> exceed the asserted upper bound, the first thing you need to do is
>> sweeping updates of the upper bounds to even try it out (to even run
>> tests), which generally turns out to reveal all is working fine.
>>
>> </rant>
>>
>>
>> Víctor Roldán Betancort wrote:
>>> Gergely,
>>>
>>> Gergely Nagy escribió:
>>>> Thanks Victor!
>>>
>>> you are welcome!
>>>
>>>> I'm trying to test a feature introduced yesterday, so I guess I'll try
>>>> to upgrade to 2.7 in my development environment. It is good to know
>>>> that
>>>> compatibility will remain with 2.6 though, as that is what our product
>>>> is currently based on.
>>>
>>> I assume at this point of the development is very unlikely that
>>> dependencies with 2.7.0 would be introduced. We (Open Canarias) also
>>> rely on 2.6.0, so we are very interested this compatibility to be kept.
>>>
>>>> In any case, the manifests will need to be
>>>> updated from 2.4, shall I file a bug about this?
>>>
>>> I really haven't tested if CDO 4.0 is compatible with < 2.6.x, but
>>> chances are it won't (as I said previously, EMF mechanisms to make
>>> Legacy Support feasible are a good example). Maybe the others could
>>> confirm this.
>>>
>>> So yes, please submit that bug, it shall serve us at least as a
>>> reminder! Please make clear in the zilla evidences are necessary for
>>> the version range to be narrowed.
>>>
>>> Cheers!
>>>
>>>> Victor Roldan Betancort wrote on Wed, 02 March 2011 12:09
>>>>> Gergely,
>>>>>
>>>>> we just regenerated our models a few days ago, and apparently
>>>>> org.eclipse.emf.ecore.util.Switch concept was recently introduced in
>>>>> EMF. Our goals is trying to stay as much compatible as possible, but
>>>>> probably the minimum version should be 2.6.0, as CDO relies on some
>>>>> new features of EMF to implement the Legacy Model Support.
>>>>>
>>>>> So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
>>>>> compatible. I'll recommend you to switch to the revision before that
>>>>> change was introduced (which I believe happened 2 days ago).
>>>>>
>>>>> We'll post here some feedback as soon as we know how to deal with the
>>>>> Switch thing ;)
>>>>>
>>>>> Cheers,
>>>>> Víctor.
>>>>>
>>>>> Gergely Nagy escribió:
>>>>> > I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors,
>>>>> for
>>>>> > example in org.eclipse.emf.cdo EresourceSwitch is missing
>>>>> > org.eclipse.emf.ecore.util.Switch.
>>>>> >
>>>>> > The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0).
>>>>> Shouldn't
>>>>> > this be [2.7.0...?
>>>>> >
>>>>> > Does this actually mean that CDO 4.0 will require EMF 2.7 when
>>>>> released?
>>>>> >
>>>>> > Greg
>>>>> >
>>>>
>>>>
>>>
|
|
|
| Re: [CDO] CDO4 depends on which EMF version? [message #657745 is a reply to message #657716] |
Thu, 03 March 2011 19:22 |
|
Am 03.03.2011 18:10, schrieb Víctor Roldán Betancort:
> Ed,
>
> I can only agree with your comments. Its something we should take better care of! We shall set some mechanisms to systematically test version range compatibility. As Eike suggest, a Hudson build with properly selected bundle versions should help. Can you think on any way to test this in our Eclipse development environments, besides switching target platform?
Switching the target platform looks like the minimum requirement ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
>
> Cheers.
>
> Ed Merks escribió:
>> Víctor,
>>
>> <rant>
>>
>> Your comment
>>
>> I really haven't tested if CDO 4.0 is compatible with < 2.6.x
>>
>> is one of the things that bugs me most about all these "hard coded"
>> version ranges in the source repository. The lower bound is set once
>> and then it's not updated again, nor (worst of all) is it ever tested to
>> check if it's valid. So lower bounds degrade into bogusness quickly
>> from release to release. The upper bound, on the other hand, is an
>> assertion that "I expect to stop working at some point." It's
>> completely baseless forecasting of the future; about as accurate as
>> Vancouver weather forecasting. Should the version ever change to exceed
>> the asserted upper bound, the first thing you need to do is sweeping
>> updates of the upper bounds to even try it out (to even run tests),
>> which generally turns out to reveal all is working fine.
>>
>> </rant>
>>
>>
>> Víctor Roldán Betancort wrote:
>>> Gergely,
>>>
>>> Gergely Nagy escribió:
>>>> Thanks Victor!
>>>
>>> you are welcome!
>>>
>>>> I'm trying to test a feature introduced yesterday, so I guess I'll try
>>>> to upgrade to 2.7 in my development environment. It is good to know that
>>>> compatibility will remain with 2.6 though, as that is what our product
>>>> is currently based on.
>>>
>>> I assume at this point of the development is very unlikely that
>>> dependencies with 2.7.0 would be introduced. We (Open Canarias) also
>>> rely on 2.6.0, so we are very interested this compatibility to be kept.
>>>
>>>> In any case, the manifests will need to be
>>>> updated from 2.4, shall I file a bug about this?
>>>
>>> I really haven't tested if CDO 4.0 is compatible with < 2.6.x, but
>>> chances are it won't (as I said previously, EMF mechanisms to make
>>> Legacy Support feasible are a good example). Maybe the others could
>>> confirm this.
>>>
>>> So yes, please submit that bug, it shall serve us at least as a
>>> reminder! Please make clear in the zilla evidences are necessary for
>>> the version range to be narrowed.
>>>
>>> Cheers!
>>>
>>>> Victor Roldan Betancort wrote on Wed, 02 March 2011 12:09
>>>>> Gergely,
>>>>>
>>>>> we just regenerated our models a few days ago, and apparently
>>>>> org.eclipse.emf.ecore.util.Switch concept was recently introduced in
>>>>> EMF. Our goals is trying to stay as much compatible as possible, but
>>>>> probably the minimum version should be 2.6.0, as CDO relies on some
>>>>> new features of EMF to implement the Legacy Model Support.
>>>>>
>>>>> So, right now TRUNK does require 2.7.0, but we inted to be 2.6.0
>>>>> compatible. I'll recommend you to switch to the revision before that
>>>>> change was introduced (which I believe happened 2 days ago).
>>>>>
>>>>> We'll post here some feedback as soon as we know how to deal with the
>>>>> Switch thing ;)
>>>>>
>>>>> Cheers,
>>>>> Víctor.
>>>>>
>>>>> Gergely Nagy escribió:
>>>>> > I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors,
>>>>> for
>>>>> > example in org.eclipse.emf.cdo EresourceSwitch is missing
>>>>> > org.eclipse.emf.ecore.util.Switch.
>>>>> >
>>>>> > The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0).
>>>>> Shouldn't
>>>>> > this be [2.7.0...?
>>>>> >
>>>>> > Does this actually mean that CDO 4.0 will require EMF 2.7 when
>>>>> released?
>>>>> >
>>>>> > Greg
>>>>> >
>>>>
>>>>
>>>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| (no subject) [message #687526 is a reply to message #687524] |
Tue, 21 June 2011 16:24 |
Eclipse User |
|
|
|
Originally posted by:
Hi guys,
I think this issue slipped through our fingers. AFAIK, CDO 4.0 has
compatibility with 2.6 (we at OpenCanarias use such configuration in one
of our products).
This is a severe problem, and too late in the development cycle :(
Do you mind submiting a bug to keep track of it?
I'm also afraid increasing the version range implies increasing CDO
version to 5.0....
Cheers,
Víctor.
Cyril Jaquier escribió:
> Hi all,
>
> I have a similar issue. I'm trying to upgrade to CDO 4.0 GA. We
> currently have EMF 2.5. org.eclipse.emf.cdo imports
> org.eclipse.emf.common.notify.impl.BasicNotifierImpl.EObservableAdapterList
> which appeared in EMF 2.6. But the Manifest still has 2.4 as minimum
> requirement.
>
> Bug?
>
> Thanks
> Cyril
>
>
> On 03/02/2011 11:55 AM, Gergely Nagy wrote:
>> I'm trying to run CDO HEAD from SVN. I'm seeing some compile errors, for
>> example in org.eclipse.emf.cdo EresourceSwitch is missing
>> org.eclipse.emf.ecore.util.Switch.
>>
>> The cdo manifest requires org.eclipse.emf.ecore[2.4.0,3.0.0). Shouldn't
>> this be [2.7.0...?
>>
>> Does this actually mean that CDO 4.0 will require EMF 2.7 when released?
>>
>> Greg
>>
>
|
|
|
| (no subject) [message #687532 is a reply to message #687526] |
Wed, 22 June 2011 06:37 |
| Eclipse User |
|
|
|
Originally posted by:
Am 21.06.2011 18:24, schrieb Víctor Roldán Betancort:
> Hi guys,
>
> AFAIK, CDO 4.0 has
> compatibility with 2.6 (we at OpenCanarias use such configuration in one
> of our products).
>
Yes, since CDO 3.0 were a bound to EMF 2.6 since the Legacy Mode,
introduced in CDO 3.0, needs EMF 2.6
Cheers,
Martin
|
|
| |
Goto Forum:
Current Time: Sat Apr 20 12:47:44 GMT 2024
Powered by FUDForum. Page generated in 0.04579 seconds |
] 
Search
Help
Register
Login
Home
