groovy 1.6 vs 1.7 conflict

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

groovy 1.6 vs 1.7 conflict

Jayet, Patrick
Hi all,

I have an Eclipse RCP app which includes the new groovy eclipse feature 2.0 [1]. My app should, for some reason, use Groovy 1.6 and not 1.7. Unfortunately, the mentioned feature includes the two groovy16 and groovy17 features, which on their turn reference two different versions of org.codehause.groovy (1.6.7.X and 1.7.0.X).

Apparently, when I have these two groovy plugin versions in my start configuration, the OSGi platform always picks the higher one, which is not what I want. Until now I was not able to include only 1.6 (when including the groovy eclipse feature). The only (ugly) solution I see, is to re-define myself all feature and plugins references by the groovy eclipse feature [1], except the one towards the groovy feature 1.7.

Is there another more elegant way to do that?

Thanks in advance.
Cheers,

Patrick


[1] org.codehaus.groovy.eclipse.feature version 2.0.0.xx-20100115-0900-e35-RELEASE


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-eclipse-plugin-dev] groovy 1.6 vs 1.7 conflict

Andrew Eisenberg
Is your RCP app based on features or on plugins?

If it is plugin based, then you should exclude the 1.7 plugin version
from your target configuration.  That would be sufficient.

If it is feature-based, then you will probably need to define a new
feature that contains all the groovy plugins that you require.  And
make sure to include an upper bound on the version number of
org.codehaus.groovy.

On Wed, Jan 20, 2010 at 7:25 AM, Jayet, Patrick <[hidden email]> wrote:

> Hi all,
>
> I have an Eclipse RCP app which includes the new groovy eclipse feature 2.0 [1]. My app should, for some reason, use Groovy 1.6 and not 1.7. Unfortunately, the mentioned feature includes the two groovy16 and groovy17 features, which on their turn reference two different versions of org.codehause.groovy (1.6.7.X and 1.7.0.X).
>
> Apparently, when I have these two groovy plugin versions in my start configuration, the OSGi platform always picks the higher one, which is not what I want. Until now I was not able to include only 1.6 (when including the groovy eclipse feature). The only (ugly) solution I see, is to re-define myself all feature and plugins references by the groovy eclipse feature [1], except the one towards the groovy feature 1.7.
>
> Is there another more elegant way to do that?
>
> Thanks in advance.
> Cheers,
>
> Patrick
>
>
> [1] org.codehaus.groovy.eclipse.feature version 2.0.0.xx-20100115-0900-e35-RELEASE
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

AW: [groovy-eclipse-plugin-dev] groovy 1.6 vs 1.7 conflict

Jayet, Patrick
Hi Andrew,

My app is feature based.

I have finally solved that problem the way I mentionned in my last e-mail (which is similar to what you suggest):
- Include all features referenced by the groovy eclipse feature in some feature I declare, except for the groovy17 feature
- As this was not enough, I had additionnaly to remove from my app's target platform the groovy17 feature and org.codehaus.groovy 1.7 plugin.

It is working, although perhaps not the most elegant solution. I'll check the way you suggest about defining my own feature referencing all groovy eclipse plugins (with a version range for org.codehaus.groovy).

Although at the moment I get an issue trying to do a product export of my app. Will post about this separately.

Cheers,
Patrick
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

AW: [groovy-eclipse-plugin-dev] groovy 1.6 vs 1.7 conflict

Jayet, Patrick
Hi Andrew,

I was thinking about that dependency problem. I think it's not optimal to have to redefine an own feature, which replicate what org.codehaus.groovy.feature does, in order to use groovy 1.6.

This problem could be easily solved, if the feature org.codehaus.groovy.eclipse.feature would not include the two features org.codehaus.groovy{16,17}.feature. Then we would just need to include the 1.6 or 1.7 groovy feature (of the version we want to use) in addition to the root groovy eclipse one. Or both if we want to be able to switch the groovy version from the preference panel (which is not working in my RCP app though).

What are your thoughts about that?

Cheers,
Patrick
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-eclipse-plugin-dev] groovy 1.6 vs 1.7 conflict

Andrew Eisenberg
The problem with not including the org,codehaus.groovy features is
that then users would need to explicitly check to include them when
installing groovy-eclipse.  If they both went unchecked, users would
get install problems and this would cause no end of problems for
everyone involved.

I could, however, mark the two features as optional.  This means that
if they are available, they will be included in the install, but if
not then they won't.  This should work for you, but I also need to
ensure that it doesn't break other kinds of installs.

Can you please raise a jira issue for this?  I'd like to be able to
track the progress of this.

--a



On Fri, Jan 22, 2010 at 1:00 AM, Jayet, Patrick <[hidden email]> wrote:

> Hi Andrew,
>
> I was thinking about that dependency problem. I think it's not optimal to have to redefine an own feature, which replicate what org.codehaus.groovy.feature does, in order to use groovy 1.6.
>
> This problem could be easily solved, if the feature org.codehaus.groovy.eclipse.feature would not include the two features org.codehaus.groovy{16,17}.feature. Then we would just need to include the 1.6 or 1.7 groovy feature (of the version we want to use) in addition to the root groovy eclipse one. Or both if we want to be able to switch the groovy version from the preference panel (which is not working in my RCP app though).
>
> What are your thoughts about that?
>
> Cheers,
> Patrick
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

AW: [groovy-eclipse-plugin-dev] groovy 1.6 vs 1.7 conflict

Jayet, Patrick
Hi Andrew,

> Can you please raise a jira issue for this?  I'd like to be able to
> track the progress of this.

Done:
http://jira.codehaus.org/browse/GRECLIPSE-632

Cheers,
Patrick
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-eclipse-plugin-dev] groovy 1.6 vs 1.7 conflict

Andrew Eisenberg
Thanks.

On Wed, Jan 27, 2010 at 6:03 AM, Jayet, Patrick <[hidden email]> wrote:

> Hi Andrew,
>
>> Can you please raise a jira issue for this?  I'd like to be able to
>> track the progress of this.
>
> Done:
> http://jira.codehaus.org/browse/GRECLIPSE-632
>
> Cheers,
> Patrick
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email