Home » Archived » Buckminster » org.eclipse.jdt.core issue - groovy support
|
| Re: org.eclipse.jdt.core issue - groovy support [message #553033 is a reply to message #553030] |
Mon, 16 August 2010 07:07   |
|
Hi Geejay,
The reason we include jdt.core (and lot's of other platform bundles) is that our headless update site is self
sufficient. If we didn't, we'd force all users to enter at least two update sites (platform and buckminster). Our
requirements are carefully set to appoint the exact same versions as the features bundled with the Eclipse IDE so I'm
not sure why this would pose any problem. If the groovy feature can be installed in the IDE, then it should be possible
to install it in a headless Buckminster too.
As an example, the Eclipse feature 'org.eclipse.jdt' (required with exact version from 'org.eclipse.sdk') has the exact
same requirement on 'org.eclipse.jdt.core'.
Why does the groovy support require another version? Seems to me that would make it impossible to use with a 3.6 IDE
unless they also provide a feature patch for 'org.eclipse.jdt'. If they do, perhaps they could provide a feature patch
that applies to all features that include 'org.eclipse.jdt.core'.
- thomas
On 08/16/2010 08:43 AM, geejay wrote:
> I was just wondering whether it is possible to follow Andrew Eisenberg's
> suggestion below in supporting Groovy compilation in Buckminster?
>
> <quote>
> HI guys,
>
> I just took a peek at your update site here:
> http://download.eclipse.org/tools/buckminster/headless-3.6/
>
> The 'org.eclipse.buckminster.pde.headless.feature feature has a tight
> dependency on org.eclipse.jdt.core v 3.6.0.v_A58. I see:
>
> <plugin
> id="org.eclipse.jdt.core"
> download-size="0"
> install-size="0"
> version="3.6.0.v_A58"
> unpack="false"/>
>
> In the feature.xml. This would need to be changed in order to support
> Groovy-Eclipse being installed.
>
> I also see that you explicitly supply that version of jdt.core in your
> update site. Is there are particular reason for this? JDT core and
> several other plugins are included in the feature, rather than being a
> dependency. Perhaps making these plugins dependencies rather than
> requirements would make it be more compatible with other tools.
> </quote>
>
>
|
|
|
| Re: org.eclipse.jdt.core issue - groovy support [message #553082 is a reply to message #553033] |
Mon, 16 August 2010 11:49 |
 Geejay
Messages: 160
Registered: February 2010 |
Senior Member |
|
|
Ok, I posted a message to the Groovy users user group. Hopefully I can get
some explanation there...
Thanks again
"Thomas Hallgren" <thomas@tada.se> wrote in message
news:i4ao36$g1j$1@build.eclipse.org...
> Hi Geejay,
>
> The reason we include jdt.core (and lot's of other platform bundles) is
> that our headless update site is self sufficient. If we didn't, we'd force
> all users to enter at least two update sites (platform and buckminster).
> Our requirements are carefully set to appoint the exact same versions as
> the features bundled with the Eclipse IDE so I'm not sure why this would
> pose any problem. If the groovy feature can be installed in the IDE, then
> it should be possible to install it in a headless Buckminster too.
>
> As an example, the Eclipse feature 'org.eclipse.jdt' (required with exact
> version from 'org.eclipse.sdk') has the exact same requirement on
> 'org.eclipse.jdt.core'.
>
> Why does the groovy support require another version? Seems to me that
> would make it impossible to use with a 3.6 IDE unless they also provide a
> feature patch for 'org.eclipse.jdt'. If they do, perhaps they could
> provide a feature patch that applies to all features that include
> 'org.eclipse.jdt.core'.
>
> - thomas
>
>
>
> On 08/16/2010 08:43 AM, geejay wrote:
>> I was just wondering whether it is possible to follow Andrew Eisenberg's
>> suggestion below in supporting Groovy compilation in Buckminster?
>>
>> <quote>
>> HI guys,
>>
>> I just took a peek at your update site here:
>> http://download.eclipse.org/tools/buckminster/headless-3.6/
>>
>> The 'org.eclipse.buckminster.pde.headless.feature feature has a tight
>> dependency on org.eclipse.jdt.core v 3.6.0.v_A58. I see:
>>
>> <plugin
>> id="org.eclipse.jdt.core"
>> download-size="0"
>> install-size="0"
>> version="3.6.0.v_A58"
>> unpack="false"/>
>>
>> In the feature.xml. This would need to be changed in order to support
>> Groovy-Eclipse being installed.
>>
>> I also see that you explicitly supply that version of jdt.core in your
>> update site. Is there are particular reason for this? JDT core and
>> several other plugins are included in the feature, rather than being a
>> dependency. Perhaps making these plugins dependencies rather than
>> requirements would make it be more compatible with other tools.
>> </quote>
>>
>>
>
|
|
|
| Re: org.eclipse.jdt.core issue - groovy support [message #553218 is a reply to message #553033] |
Mon, 16 August 2010 17:15 |
Andrew Eisenberg
Messages: 382
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
I understand that you want to have a self-contained update site, but it should be possible to do so without having the buckminster features include the jdt plugins.
There are two possibilities that I can see:
1 Add the inclusion at the feature level.
Using something like in the feature.xml:
<includes
id="org.eclipse.jdt"
version="3.6.0.WHATEVER"
name=""/>
So, even though your feature would have a hard requirement on a particular version of jdt, any feature patch would still be able to work since you don't have a hard requirement on any particular plugin inside of jdt.
2. Add the plugin to the list of required plugins and still provide all of the p2 artifacts from the same update site. p2 should be able to determine that if the particular artifacts are not currently installed, but are available, then they will be installed too.
I think #1 is the better choice, but it might require playing around a bit to see which is actually better in your situation.
As to answer your question, yes, Groovy-Eclipse does provide a feature patch for jdt. However, I am reluctant to also provide patches for all other features out there that include jdt since this list is open ended and constantly changing. Furthermore, this would become very difficult to maintain as we would have to stay on top of all upgrades to all features. And another problem is that Groovy-Eclipse is not the only feature patch to jdt core out there. There are other language IDEs that provide feature patches.
So, I do not think that this solution is tenable. Rather, it seems like it would be better that the solution comes from the buckminster build since it would be relatively easy to fix by simply rearranging your build artifacts.
|
|
|
| Re: org.eclipse.jdt.core issue - groovy support [message #553237 is a reply to message #553218] |
Mon, 16 August 2010 18:01 |
|
On 08/16/2010 07:15 PM, Andrew Eisenberg wrote:
> Hi Thomas,
>
> I understand that you want to have a self-contained update site, but it
> should be possible to do so without having the buckminster features
> include the jdt plugins.
>
> There are two possibilities that I can see:
>
>
> 1 Add the inclusion at the feature level.
>
> Using something like in the feature.xml:
>
> <includes
> id="org.eclipse.jdt"
> version="3.6.0.WHATEVER"
> name=""/>
>
> So, even though your feature would have a hard requirement on a
> particular version of jdt, any feature patch would still be able to work
> since you don't have a hard requirement on any particular plugin inside
> of jdt.
>
That doesn't work since the org.eclipse.jdt feature brings in a slew of bundles that have UI dependencies. We only want
the headless stuff.
> 2. Add the plugin to the list of required plugins and still provide all
> of the p2 artifacts from the same update site. p2 should be able to
> determine that if the particular artifacts are not currently installed,
> but are available, then they will be installed too.
>
True, but that breaks the whole notion of feature packaging. Suddenly, there's nothing at all that appoints a specific
version of the org.eclipse.jdt.core bundle. It's version is thus floating and the install is no longer reproducible. The
chance of reverting to an older version is completely lost.
Another thing to consider is that our build is performed using the specific version of org.eclipse.jdt.core that we
ship. All tests run with that bundle. It's possible that they would also run with another version but then again,
chances are that something would fail.
That said, I'm not foreign to having includes with more lax version ranges. In fact, I had a very long discussion with
Jeff McAffer during the Helios milestones because we used Buckminster's ability to generate such ranges. The ECF project
has some thoughts in the same direction right now. The topic is somewhat controversial and Jeff writes a good summary here:
http://dev.eclipse.org/mhonarc/lists/rt-pmc/msg01979.html
> I think #1 is the better choice, but it might require playing around a
> bit to see which is actually better in your situation.
>
> As to answer your question, yes, Groovy-Eclipse does provide a feature
> patch for jdt. However, I am reluctant to also provide patches for all
> other features out there that include jdt since this list is open ended
> and constantly changing. Furthermore, this would become very difficult
> to maintain as we would have to stay on top of all upgrades to all
> features. And another problem is that Groovy-Eclipse is not the only
> feature patch to jdt core out there. There are other language IDEs that
> provide feature patches.
> So, I do not think that this solution is tenable. Rather, it seems like
> it would be better that the solution comes from the buckminster build
> since it would be relatively easy to fix by simply rearranging your
> build artifacts.
We are very anxious to resolve this problem, one way or another. Perhaps by providing a special headless groovy support
feature from our external update site, or by other means. A feature patch, etc. I'm not sure at this point.
What's the nature of your patch to org.eclipse.jdt.core? Has it been submitted to Eclipse?
Regards,
Thomas Hallgren
|
|
|
| Re: org.eclipse.jdt.core issue - groovy support [message #553469 is a reply to message #553237] |
Tue, 17 August 2010 15:48 |
Andrew Eisenberg
Messages: 382
Registered: July 2009 |
Senior Member |
|
|
I forgot that buckminster cannot use UI components, so I am beginning to see why you had to create your own feature.
But, for my other possible suggestion, is it not possible to add ranges on the required plugins so that you are sure to get a version within a specific range?
I know that you test against a particular version of JDT, and you are concerned about compatibility. But what happens when 3.6.1 comes out? Will you have 2 update sites, or will you require all buckminster users to upgrade? What I am suggesting here is that it may not be desirable to force users onto a specific version of 3.6.x version. Since you can control the acceptable version ranges, you can make the range of acceptible versions as narrow as you want.
You mention the possibility of widening the range acceptible by the includes directive inside of a feature, but fundamentally, how different is that to having a requirement on individual plugins? If you are concerned about compatibility across service refreshes, then the problem would still exist if you take this approach.
As for your last question, the feature patch that we use includes a few changes to jdt.core that open up hooks so that the Groovy compiler can be run along side the java compiler.
All of these changes deal with opening up the compiler for use with other languages, rather than actual fixes to the compiler itself. Some of these changes are general purpose and can theoretically be consumed by other languages building on top of jdt, but many are groovy-specific. There is a long standing bugzilla request to have a look at this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=36939
And there is talk about integrating some of these ideas into an e4 project, but nothing yet. So, no, this feature patch cannot be submitted to the JDT team at this point.
|
|
|
| Re: org.eclipse.jdt.core issue - groovy support [message #553545 is a reply to message #553469] |
Tue, 17 August 2010 21:20 |
|
Hi Andrew,
I've been considering several solutions and I think the best thing for us to do is to change the includes of all
platform bundles to bundle requirements with ranges.
The result will be an install where no feature controls the exact version of these bundles which will lead to some
difficulties should you ever want to downgrade but in a headless scenario I don't think that will matter much. It's easy
enough to just wipe out the installation and reinstall from scratch.
I entered https://bugs.eclipse.org/bugs/show_bug.cgi?id=322959 to track this work.
Regards,
Thomas Hallgren
On 08/17/2010 05:48 PM, Andrew Eisenberg wrote:
> I forgot that buckminster cannot use UI components, so I am beginning to
> see why you had to create your own feature.
>
> But, for my other possible suggestion, is it not possible to add ranges
> on the required plugins so that you are sure to get a version within a
> specific range?
>
> I know that you test against a particular version of JDT, and you are
> concerned about compatibility. But what happens when 3.6.1 comes out?
> Will you have 2 update sites, or will you require all buckminster users
> to upgrade? What I am suggesting here is that it may not be desirable to
> force users onto a specific version of 3.6.x version. Since you can
> control the acceptable version ranges, you can make the range of
> acceptible versions as narrow as you want.
>
> You mention the possibility of widening the range acceptible by the
> includes directive inside of a feature, but fundamentally, how different
> is that to having a requirement on individual plugins? If you are
> concerned about compatibility across service refreshes, then the problem
> would still exist if you take this approach.
>
> As for your last question, the feature patch that we use includes a few
> changes to jdt.core that open up hooks so that the Groovy compiler can
> be run along side the java compiler.
>
> All of these changes deal with opening up the compiler for use with
> other languages, rather than actual fixes to the compiler itself. Some
> of these changes are general purpose and can theoretically be consumed
> by other languages building on top of jdt, but many are groovy-specific.
> There is a long standing bugzilla request to have a look at this:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36939
>
> And there is talk about integrating some of these ideas into an e4
> project, but nothing yet. So, no, this feature patch cannot be submitted
> to the JDT team at this point.
|
|
| |
| Re: org.eclipse.jdt.core issue - groovy support [message #553626 is a reply to message #553545] |
Wed, 18 August 2010 08:40 |
Geejay
Messages: 160
Registered: February 2010 |
Senior Member |
|
|
Thanks for the help guys. In the meantime, is it possible to compile the
Groovy code with an Ant task and call that Ant task from Buckminster
somehow?
"Thomas Hallgren" <thomas@tada.se> wrote in message
news:i4euea$u6f$1@build.eclipse.org...
> Hi Andrew,
>
> I've been considering several solutions and I think the best thing for us
> to do is to change the includes of all platform bundles to bundle
> requirements with ranges.
>
> The result will be an install where no feature controls the exact version
> of these bundles which will lead to some difficulties should you ever want
> to downgrade but in a headless scenario I don't think that will matter
> much. It's easy enough to just wipe out the installation and reinstall
> from scratch.
>
> I entered https://bugs.eclipse.org/bugs/show_bug.cgi?id=322959 to track
> this work.
>
> Regards,
> Thomas Hallgren
>
>
> On 08/17/2010 05:48 PM, Andrew Eisenberg wrote:
>> I forgot that buckminster cannot use UI components, so I am beginning to
>> see why you had to create your own feature.
>>
>> But, for my other possible suggestion, is it not possible to add ranges
>> on the required plugins so that you are sure to get a version within a
>> specific range?
>>
>> I know that you test against a particular version of JDT, and you are
>> concerned about compatibility. But what happens when 3.6.1 comes out?
>> Will you have 2 update sites, or will you require all buckminster users
>> to upgrade? What I am suggesting here is that it may not be desirable to
>> force users onto a specific version of 3.6.x version. Since you can
>> control the acceptable version ranges, you can make the range of
>> acceptible versions as narrow as you want.
>>
>> You mention the possibility of widening the range acceptible by the
>> includes directive inside of a feature, but fundamentally, how different
>> is that to having a requirement on individual plugins? If you are
>> concerned about compatibility across service refreshes, then the problem
>> would still exist if you take this approach.
>>
>> As for your last question, the feature patch that we use includes a few
>> changes to jdt.core that open up hooks so that the Groovy compiler can
>> be run along side the java compiler.
>>
>> All of these changes deal with opening up the compiler for use with
>> other languages, rather than actual fixes to the compiler itself. Some
>> of these changes are general purpose and can theoretically be consumed
>> by other languages building on top of jdt, but many are groovy-specific.
>> There is a long standing bugzilla request to have a look at this:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=36939
>>
>> And there is talk about integrating some of these ideas into an e4
>> project, but nothing yet. So, no, this feature patch cannot be submitted
>> to the JDT team at this point.
>
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 18:17:34 GMT 2024
Powered by FUDForum. Page generated in 0.03872 seconds |
] 
Search
Help
Register
Login
Home
