Buliding against Indigo

[emolitor]

I've posted the changes I made to build the IDE against Eclipse Indigo on the indigo branch of git://git.assembla.com/emolitor-scala-ide-indigo.git I've only run through some simple tests but its working well for me. I'm going to start looking at what is necessary to build against 4.1. This should be a bit more interesting as the while the JDT is the same the UI code is quite different. Feel free to pull in changes you believe will help others. (CLA has been signed and acknowledged by EPFL)

- Eric

[emolitor]

Below is the update site I've posted the builds on to test with.

http://scala-ide.s3.amazonaws.com

- Eric

[Miles Sabin]

Good stuff ... does this build function correctly with Helios as well?

Cheers,

Miles

--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

[emolitor]

I've not tested it on Helios and believe that it would not. I'm using AJDT 2.1.3 release for 3.7 which I suspect will cause issues with Helios. And some of the signature changes would be painful to support. In several places they've changed the API to return the concrete implementation of SpellingProvider instead of the Interface. There are other similar changes that could be fixed but would be painful.

- Eric

[emolitor]

Could certainly merge in the tycho changes and various other bits and bobs.

[David Bernard]

Thanks Eric.

You're change was based on which branch (wip_exp_backport or wip_experiment) ?

Side-Notes : 

I was so happy we no longer need to provide an update-site peer eclipse version (galileo and helios).

Need to create one for helios/galileo and an other for indigo will again increase work (mantaince, branch) :-(

But It's sure (80%) we'll have to create one for eclipse 4.x.

/davidB

[David Bernard]

I found it's based on wip_experiment (I asked because you reply to a ticket about wip_exp_backport (aka version 1.x.y).

I don't understand the nee to replace ISpellEngine by class from "jdt's internal", Why ?

[emolitor]

Ahhh ok then you are correct. You can ignore my comments as my work was based on wip_experiment. For 4.xx I would be shocked if we can remain on a single version. However if we embrace having multiple version then I think it can be managed cleanly. Essentially split the source into a core package and specific pacakges for 4.xx and 3.x support.

- Eric

[emolitor]

This weekend I'll create a set of changes that I think could/should be merged into wip_experimental that are compatible with 3.6 and 3.7.

- Eric

[ijuma]

On Tuesday, 2 August 2011 17:42:54 UTC+1, emolitor wrote:

Ahhh ok then you are correct. You can ignore my comments as my work was based on wip_experiment. For 4.xx I would be shocked if we can remain on a single version.

Note that Eclipse 4.x SDK includes a compatibility package. Much of the code outside of platform works on both 3.x and 4.x, so I think a single version should be possible.

Best,

Ismael

[John Eckhart]

Outside of some changes to the perspective bar (and how scala-ide registers it's perspective) I found that it would run with very little change on 4.1. I'll try to dig up the patch needed to run in 4.1 (based on one of the 2.0 betas). This was still using 3.6 (Helios) to compile against. If you want to build specifically against 4.1 then I'm sure some more changes would be necessary.

- John

[emolitor]

Patch would always be helpful but I do plan on building against 4.1.

[Ronald Steinhau]

Would it be possible to change the dependencies on the trunk/
experiment branch for eclipse JDT (and other) dependencies, so that
it is possible to use the 3.8 (Juno) milestones. I think, there will
be no more major changes in JDT, so it seems to be no real risk and
everybody can decide to use a milestone or stay with 3.7.

Best regards,
Ronald Steinhau

[emolitor]

Updated my fork and pushed packages to my test update site http://scala-ide.s3.amazonaws.com 

* Merged changes from upstream/wip_experiment.

* Disabled hyperlink unit test that is failing for 2.9.1.

* Using the 3.7.1 Indigo milestone to allow building with JDK 7.

- Eric

[emolitor]

The changes to support Juno are just a few minor changes after building against Indigo. I've merged those into my Indigo branch now and tested with both 3.7 and 4.2. You can use my test update site to see if it works for you. 

http://scala-ide.s3.amazonaws.com

Now that I have Indigo and Juno happy I'm looking at adding a few compatibility changes to allow Helios to work. They will be similar to the Helios/Juno initialization in GeneralScalaJavaBuilder.scala and just use conditional checks to determine if we're on Helios and then use reflection to initialize the Builder, SpellChecker, and a few other things whose interfaces have changed.

- Eric

[iulian dragos]

Are you able to use the same sources to build against Helios and
Indigo? Or you updated the sources to compile against Indigo, and add
the necessary runtime checks for running on Helios (basically, the
opposite of what we're doing now to support Indigo).

iulian

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[emolitor]

It's the same source built against Indigo but works for 3.6, 3.7, and 4.2M1. (3.6 needs more testing but I was able to build and run applications)

The changes loosely fit into two buckets. Changes that I need to clean up and could be applied now and changes that are best to be applied after the IDE starts building against 3.7. I do think there is an argument that the IDE should start building against 3.7 soon but not sure how that fits into the release plans for the IDE.

- Eric

[iulian dragos]

It would help to know how many people use (or would use) Scala on
Indigo vs. Helios. I'd prefer to stay on Helios as long as it is the
main installation. I think David worked on code that would retrive
that information when people install the IDE, but I'm not sure what's
the status.

I just sent a one-question form :) to scala-ide-user@, and we'll see
what's the reaction.

iulian

[emolitor]

There is also the contra-argument that says we should wait for Eclipse 3.7.1 which fixes JDK 7 and several other issues in the 3.7.0 release. :)

- Eric

[Matthew Farwell]

My two pennyworth:

As long as I use Scala for personal stuff, I don't really care whether it's on Indigo or Helios (or even 4.x). However, if I use Scala for real stuff (work), then it becomes harder to continually upgrade, not because of Scala, but because other things may change. Inertia becomes a problem.

For instance, when I upgraded a (java) project recently from Galileo to Helios, I had some differences in behaviour for maven plugins (m2eclipse), along with some subtle changes in the behaviour of STS. This took time to resolve.

My point is that some people can't upgrade as quickly and as easily as you lot :-) I would keep the Helios support as long as possible, unless it becomes a serious pain to support.

As far as usage data is concerned, Eclipse already has a method for doing this, the Usage Data Collector. (http://www.eclipse.org/epp/usagedata/). I have no idea how to make this data be collected, or once it has been collected how to access the data (the site only seems to show org.eclipse stuff), but surely that's the way to go to find out real usage patterns. It's weird, but on my machine the scala bundles are all greyed out in the usage data collector. I don't understand it.

The other source of information would be the bugs in assembla raised for each version, but this is obviously skewed because it only includes people who care :-)

Matthew Farwell. 

2011/8/30 iulian dragos <jagu...@gmail.com>

[Ronald Steinhau]

Please don't forget the "target" option - using Eclipse 4.2 as a
development environment but using Helios as a target. If this is
working, every developer can decide which version of the IDE to work
in, but still develop for "legacy" applications. In that respect it
would be helpful to split the scala-plugins into a runtime part (just
the libraries and the compiler) and the IDE (only) part (needed in the
development environment). Only special projects may need the IDE part
in their target, too (e.g. you guys), but usually this is not the
case. Also one might double-check, if SBT is really using the target
classpath's (and not the IDE ones), when a target is specified.
Ronald Steinhau

On Aug 30, 5:26 pm, Matthew Farwell <matt...@farwell.co.uk> wrote:
> My two pennyworth:
>
> As long as I use Scala for personal stuff, I don't really care whether it's
> on Indigo or Helios (or even 4.x). However, if I use Scala for real stuff
> (work), then it becomes harder to continually upgrade, not because of Scala,
> but because other things may change. Inertia becomes a problem.
>
> For instance, when I upgraded a (java) project recently from Galileo to
> Helios, I had some differences in behaviour for maven plugins (m2eclipse),
> along with some subtle changes in the behaviour of STS. This took time to
> resolve.
>
> My point is that some people can't upgrade as quickly and as easily as you
> lot :-) I would keep the Helios support as long as possible, unless it
> becomes a serious pain to support.
>
> As far as usage data is concerned, Eclipse already has a method for doing
> this, the Usage Data Collector. (http://www.eclipse.org/epp/usagedata/). I
> have no idea how to make this data be collected, or once it has been
> collected how to access the data (the site only seems to show org.eclipse
> stuff), but surely that's the way to go to find out real usage patterns.
> It's weird, but on my machine the scala bundles are all greyed out in the
> usage data collector. I don't understand it.
>
> The other source of information would be the bugs in assembla raised for
> each version, but this is obviously skewed because it only includes people
> who care :-)
>
> Matthew Farwell.
>

> 2011/8/30 iulian dragos <jagua...@gmail.com>
>
>
>
>
>
>
>
> > On Mon, Aug 29, 2011 at 10:26 PM, emolitor <mrericmoli...@gmail.com>

[emolitor]

Right now I'm actually Indigo it just happens that the build seems to work well for Helios and with a few minor modifications works with Juno. It all needs a bit more testing to find out how well it works with Helios. :)

- Eric

[David Bernard]

On Tue, Aug 30, 2011 at 17:26, Matthew Farwell <mat...@farwell.co.uk> wrote:

My two pennyworth:

As long as I use Scala for personal stuff, I don't really care whether it's on Indigo or Helios (or even 4.x). However, if I use Scala for real stuff (work), then it becomes harder to continually upgrade, not because of Scala, but because other things may change. Inertia becomes a problem.

For instance, when I upgraded a (java) project recently from Galileo to Helios, I had some differences in behaviour for maven plugins (m2eclipse), along with some subtle changes in the behaviour of STS. This took time to resolve.

My point is that some people can't upgrade as quickly and as easily as you lot :-) I would keep the Helios support as long as possible, unless it becomes a serious pain to support.

As far as usage data is concerned, Eclipse already has a method for doing this, the Usage Data Collector. (http://www.eclipse.org/epp/usagedata/). I have no idea how to make this data be collected, or once it has been collected how to access the data (the site only seems to show org.eclipse stuff), but surely that's the way to go to find out real usage patterns. It's weird, but on my machine the scala bundles are all greyed out in the usage data collector. I don't understand it.

The other source of information would be the bugs in assembla raised for each version, but this is obviously skewed because it only includes people who care :-)

Before working on a home made way to collecte usage data, I explore the way about the eclipse native feature, but I didn't find how a third party can access info about its own plugin.

I'm experimenting/testing the collector (basic) on the wip_exp_backport branch since one week (I use GoogleAnalytics, and there is a long delay for feedback (several hours) => increase time to test/debug).

You can browse and read README (current state) at https://www.assembla.com/code/scala-ide/git/nodes/org.scala-ide.tracker?rev=102363af4f8840f357fdecfdc95f14c406e1bfe1

/davidB

[emolitor]

http://scala-ide.s3.amazonaws.com has been updated with changes merged from the latest release. I'm off on holiday for a few weeks but would like to discuss posting that update site for Indigo/Juno users on the downloads page at ScalaLOL 2011 when I return. (Perhaps tagged as experimental.) At this point I believe its stable enough (should be as stable as wip_experiment) to start gathering more feedback and users.

- Eric