scala-compiler.jar in eclipse

On Wed, Sep 2, 2009 at 7:17 PM, Kevin
Wright wrote:
> What approach are various people currently taking to add scala-compiler.jar
> to the classpath in an eclipse project?

Do you need scala-compiler.jar on the classpath? Can't you just add
the compiler project as a project-level dependency?

This is for developing a compiler plugin in Eclipse, right? I was
under the impression that that pretty much Just Works?

Cheers,

Miles

The compiler project isn't compiling for me right now :(
In general, I'd rather not have to rely on the compiler source project, which regularly has broken builds under windows
Plus, keeping a large project open just to use as a dependency is not exactly easy-going on the old heap space...

On Wed, Sep 2, 2009 at 7:52 PM, Miles Sabin <miles@milessabin.com> wrote:

On Wed, Sep 2, 2009 at 7:17 PM, Kevin
Wright<kev.lee.wright@googlemail.com> wrote:
> What approach are various people currently taking to add scala-compiler.jar
> to the classpath in an eclipse project?

Do you need scala-compiler.jar on the classpath? Can't you just add
the compiler project as a project-level dependency?

This is for developing a compiler plugin in Eclipse, right? I was
under the impression that that pretty much Just Works?

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Wed, Sep 2, 2009 at 7:17 PM, Kevin
Wright wrote:
> Until recently, I was able to remove the plugin's classpath container and
> manually add all 4 jars from the latest Scala svn build.  When I try this
> now, I get "scala.tools.nsc.MissingRequirementError: class
> scala.reflect.ClassManifest not found.", so it looks like this isn't a
> viable approach any more :(
> All suggestions are welcomed!

Umm ... quick sanity check ... are you updating the Scala IDE
everytime you update your scala-compiler.jar and scala-library.jar?

Cheers,

Miles

On Wed, Sep 2, 2009 at 8:05 PM, Kevin
Wright wrote:
> The compiler project isn't compiling for me right now :(
> In general, I'd rather not have to rely on the compiler source project,
> which regularly has broken builds under windows
> Plus, keeping a large project open just to use as a dependency is not
> exactly easy-going on the old heap space...

Well, YMMV, but I would have thought having the compiler sources
around while working on a compiler plugin would be quite useful ;-)

Cheers,

Miles

Not really, the sort of things I want to know are:
1. Which source file contains class/trait XXX?2. What variables/objects/methods are currently in scope?
The eclipse plugin, as it currently stands, could help with 1 - but it gets upset as the project isn't building; so a text search is just as effective.
For 2. I know you have auto-completion coming soon, so I'm waiting on that with bated breath - but presumably it'll work against jar imports too?
Scaladoc for the compiler would be of most use to me right now, but it isn't published anywhere that I can find, and the docscomp target isn't working either.




On Wed, Sep 2, 2009 at 8:14 PM, Miles Sabin <miles@milessabin.com> wrote:

On Wed, Sep 2, 2009 at 8:05 PM, Kevin
Wright<kev.lee.wright@googlemail.com> wrote:
> The compiler project isn't compiling for me right now :(
> In general, I'd rather not have to rely on the compiler source project,
> which regularly has broken builds under windows
> Plus, keeping a large project open just to use as a dependency is not
> exactly easy-going on the old heap space...

Well, YMMV, but I would have thought having the compiler sources
around while working on a compiler plugin would be quite useful ;-)

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Wed, Sep 2, 2009 at 8:37 PM, Kevin
Wright wrote:
> Not really, the sort of things I want to know are:
> 1. Which source file contains class/trait XXX?
> 2. What variables/objects/methods are currently in scope?
> The eclipse plugin, as it currently stands, could help with 1 - but it gets
> upset as the project isn't building; so a text search is just as effective.

I thought the Windows build issues had been fixed?

Cheers,

Miles

Living in hope, as always!
I've just updated everything in sight and I'm running a full clean/dist cycle in ant to see if that helps.
Good news is that somewhere between updating the plugin and flushing cached metadata I've managed to lose the compiler errors in eclipse, so fingers crossed...
For future use, would it be much work to supply an additional classpath container in the plugin that provides scala-compiler.jar?  This would be a necessary step anyway if any of us ever finds the time to extend the IDE support and offer a project type of "eclipse compiler plugin" :)


On Wed, Sep 2, 2009 at 8:51 PM, Miles Sabin <miles@milessabin.com> wrote:

On Wed, Sep 2, 2009 at 8:37 PM, Kevin
Wright<kev.lee.wright@googlemail.com> wrote:
> Not really, the sort of things I want to know are:
> 1. Which source file contains class/trait XXX?
> 2. What variables/objects/methods are currently in scope?
> The eclipse plugin, as it currently stands, could help with 1 - but it gets
> upset as the project isn't building; so a text search is just as effective.

I thought the Windows build issues had been fixed?

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Wed, Sep 2, 2009 at 9:06 PM, Kevin
Wright wrote:
> For future use, would it be much work to supply an additional classpath
> container in the plugin that provides scala-compiler.jar?  This would be a
> necessary step anyway if any of us ever finds the time to extend the IDE
> support and offer a project type of "eclipse compiler plugin" :)

Hmm ... interesting idea. It hadn't occurred to me because I always
have the compiler project checked out but, yes, I can see that an
optional compiler classpath container bundling the compiler .jar with
a source attachment would be very useful for compiler plugin
developers.

Any volunteers willing to whip up a patch?

Cheers,

Miles

I'm happy to look into it - it scratches a personal itch, but have approximately 0 experience on plugin development, so I'd truly have no idea where to start

On Wed, Sep 2, 2009 at 9:24 PM, Miles Sabin <miles@milessabin.com> wrote:

On Wed, Sep 2, 2009 at 9:06 PM, Kevin
Wright<kev.lee.wright@googlemail.com> wrote:
> For future use, would it be much work to supply an additional classpath
> container in the plugin that provides scala-compiler.jar?  This would be a
> necessary step anyway if any of us ever finds the time to extend the IDE
> support and offer a project type of "eclipse compiler plugin" :)

Hmm ... interesting idea. It hadn't occurred to me because I always
have the compiler project checked out but, yes, I can see that an
optional compiler classpath container bundling the compiler .jar with
a source attachment would be very useful for compiler plugin
developers.

Any volunteers willing to whip up a patch?

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

By the way, Miles, what exactly is your Eclipse setup during plugin
development? It took me quite a while to get things working on Eclipse
3.5. For example, which version of the plugin to have installed?

On Wed, Sep 2, 2009 at 5:47 PM, Kevin
Wright wrote:
> I'm happy to look into it - it scratches a personal itch, but have
> approximately 0 experience on plugin development, so I'd truly have no idea
> where to start
>
> On Wed, Sep 2, 2009 at 9:24 PM, Miles Sabin wrote:
>>
>> On Wed, Sep 2, 2009 at 9:06 PM, Kevin
>> Wright wrote:
>> > For future use, would it be much work to supply an additional classpath
>> > container in the plugin that provides scala-compiler.jar?  This would be
>> > a
>> > necessary step anyway if any of us ever finds the time to extend the IDE
>> > support and offer a project type of "eclipse compiler plugin" :)
>>
>> Hmm ... interesting idea. It hadn't occurred to me because I always
>> have the compiler project checked out but, yes, I can see that an
>> optional compiler classpath container bundling the compiler .jar with
>> a source attachment would be very useful for compiler plugin
>> developers.
>>
>> Any volunteers willing to whip up a patch?
>>
>> Cheers,
>>
>>
>> Miles
>>
>> --
>> Miles Sabin
>> tel: +44 (0)7813 944 528
>> skype:  milessabin
>> http://www.chuusai.com/
>> http://twitter.com/milessabin
>
>

> Scaladoc for the compiler would be of most use to me right now, but it
> isn't published anywhere that I can find, and the docscomp target isn't
> working either.

I can't build the scaladoc either, so I've generated sxr'd sources instead.
You can find them here:

http://harrah.github.com/browse/samples/

Thanks,
Mark

> On Wed, Sep 2, 2009 at 8:14 PM, Miles Sabin wrote:
> > On Wed, Sep 2, 2009 at 8:05 PM, Kevin
> >
> > Wright wrote:
> > > The compiler project isn't compiling for me right now :(
> > > In general, I'd rather not have to rely on the compiler source project,
> > > which regularly has broken builds under windows
> > > Plus, keeping a large project open just to use as a dependency is not
> > > exactly easy-going on the old heap space...
> >
> > Well, YMMV, but I would have thought having the compiler sources
> > around while working on a compiler plugin would be quite useful ;-)
> >
> > Cheers,
> >
> >
> > Miles
> >
> > --
> > Miles Sabin
> > tel: +44 (0)7813 944 528
> > skype: milessabin
> > http://www.chuusai.com/
> > http://twitter.com/milessabin

+about 1,000,000 - or thereabouts

On Thursday, September 3, 2009, Mark Harrah wrote:
>> Scaladoc for the compiler would be of most use to me right now, but it
>> isn't published anywhere that I can find, and the docscomp target isn't
>> working either.
>
> I can't build the scaladoc either, so I've generated sxr'd sources instead.
> You can find them here:
>
> http://harrah.github.com/browse/samples/
>
> Thanks,
> Mark
>
>> On Wed, Sep 2, 2009 at 8:14 PM, Miles Sabin wrote:
>> > On Wed, Sep 2, 2009 at 8:05 PM, Kevin
>> >
>> > Wright wrote:
>> > > The compiler project isn't compiling for me right now :(
>> > > In general, I'd rather not have to rely on the compiler source project,
>> > > which regularly has broken builds under windows
>> > > Plus, keeping a large project open just to use as a dependency is not
>> > > exactly easy-going on the old heap space...
>> >
>> > Well, YMMV, but I would have thought having the compiler sources
>> > around while working on a compiler plugin would be quite useful ;-)
>> >
>> > Cheers,
>> >
>> >
>> > Miles
>> >
>> > --
>> > Miles Sabin
>> > tel: +44 (0)7813 944 528
>> > skype:  milessabin
>> > http://www.chuusai.com/
>> > http://twitter.com/milessabin
>
>
>

By the way, I've been able to get the compiler scaladoc to generate by
adding ${jline.jar} to pack.classpath. I haven't tried lately so there
might be something else breaking it now.

Yeah, I posted that fix a while back, looks like it still hasn't been added in SVN though. :(
I was also getting MSIL failures that ultimately blocked the build and the document generation.  Could be worth trying again though, now that the regular build seems to be fixed on windows.


A bigger problem is when I do an SVN update, then a dist build.  If the build fails then the previous docs have been lost and can't easily be regenerated.  I'm obviously going to have to take backups (if I ever manage to build a working set...), but still think that compiler scaladocs should be included in the hudson build - just as library scaladocs are.
On Fri, Sep 4, 2009 at 12:54 AM, Geoff Reedy <geoff@programmer-monk.net> wrote:

By the way, I've been able to get the compiler scaladoc to generate by
adding ${jline.jar} to pack.classpath. I haven't tried lately so there
might be something else breaking it now.

On Fri, Sep 4, 2009 at 1:02 AM, Kevin
Wright wrote:
> A bigger problem is when I do an SVN update, then a dist build.

Depending on the phase of the moon you might be able to get away with
skipping the clean and just running the fastdist target ... this can
save you a lot of time. There's also a devel-fastdist target in
scala-plugin/build.xml which does the same in the context of IDE
builds.

Cheers,

Miles

On Fri, Sep 4, 2009 at 11:13 AM, Miles Sabin <miles@milessabin.com> wrote:

On Fri, Sep 4, 2009 at 1:02 AM, Kevin
Wright<kev.lee.wright@googlemail.com> wrote:
> A bigger problem is when I do an SVN update, then a dist build.

Depending on the phase of the moon you might be able to get away with
skipping the clean and just running the fastdist target ... this can
save you a lot of time. There's also a devel-fastdist target in
scala-plugin/build.xml which does the same in the context of IDE
builds.

Cheers,

Miles

Interesting... We could set up a whole new "warewolf coding" cliché here!
I wonder if anyone's tried to recruit a few supernatural programmers into the cult of scala yet :)

Miles Sabin wrote:

> have the compiler project checked out but, yes, I can see that an
> optional compiler classpath container bundling the compiler .jar with
> a source attachment would be very useful for compiler plugin
> developers.

Sounds like a job for Ivy - the compiler build publishes an Ivy metadata
file (maven metadata works too), and the user's compiler plugin project
includes an IvyDE classpath container which depends on the compiler.
Updating to the latest compiler would be a one-click operation.

Actual integration into the eclipse plugin could be nice, so it
automatically updates to the latest nightly or such, but perhaps not worth
the effort.

cheers

alex

Not quite the same idea, but could be made to work....

The scala build already has hooks to publish maven metadata, so you could attempt to use that locally in the eclipse  build if you wanted to rely on the IvyDE.  Or you can point to the ones available on www.scala-tools.org

I personally use IAM + the maven integration to pull the scala-compiler.jar (and source) into the classpath when needed.  With recent releases of IAM and the 2.8 eclipse plugin, it looks like I might have to revive the Eclipse-Scala-Maven project again.  I was hoping it would be unecessary due to things working much better without any extra plugins.   Oh well....


- Josh

On Sun, Sep 6, 2009 at 4:48 AM, Alex Iliev <sasho@cs.dartmouth.edu> wrote:

Miles Sabin wrote:

have the compiler project checked out but, yes, I can see that an
optional compiler classpath container bundling the compiler .jar with
a source attachment would be very useful for compiler plugin
developers.

Sounds like a job for Ivy - the compiler build publishes an Ivy metadata file (maven metadata works too), and the user's compiler plugin project includes an IvyDE classpath container which depends on the compiler. Updating to the latest compiler would be a one-click operation.

Actual integration into the eclipse plugin could be nice, so it automatically updates to the latest nightly or such, but perhaps not worth the effort.

cheers

alex

On Tue, Sep 8, 2009 at 4:25 AM, Josh Suereth wrote:
> With recent releases of IAM
> and the 2.8 eclipse plugin, it looks like I might have to revive the
> Eclipse-Scala-Maven project again.  I was hoping it would be unecessary due
> to things working much better without any extra plugins.   Oh well....

I was under the impression that 2.8 would improve the situation for
Maven users. Can you say what the new problems are?

Cheers,

Miles

I'm starting to wonder if this thread has diverged a bit to far from the original query...
This is an issue that should only affect people on the bleeding edge (i.e. trunk) where the plugin is potentially working with a different version of scala-library every day.
Essentially, I also want to add to my project the scala-compiler.jar that was built at the same time as the supplied scala-library.  SBT/Ivy/Maven etc. are all great solutions and I do use them.
The problem then is that the eclipse plugin could be supplying one version of scala library while (e.g.) maven is supplying another version that's one day newer - this can cause some *very* frustrating and hard to diagnose problems.  Of course, this simply wont be an issue for stable releases.

Therefore, I want to allow the eclipse plugin to supply scala-library, scala-compiler, etc. for me, which means that when I update the plugin I can be sure everything is both and synchronised and at the very bleeding edge
On Tue, Sep 8, 2009 at 9:21 AM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Sep 8, 2009 at 4:25 AM, Josh Suereth<joshua.suereth@gmail.com> wrote:
> With recent releases of IAM
> and the 2.8 eclipse plugin, it looks like I might have to revive the
> Eclipse-Scala-Maven project again.  I was hoping it would be unecessary due
> to things working much better without any extra plugins.   Oh well....

I was under the impression that 2.8 would improve the situation for
Maven users. Can you say what the new problems are?

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

It's actually the IAM plugin is running the maven-scala-plugin as well as the "Scala Builder".  It looks like (due to upgrades to IAM), I need to go back and make the ESMi plugin work again, as the "Add Scala Nature" won't quite be enough to synch the two plugins (at least not without wasted compute cycles... I hate lon gbuild times).

On Tue, Sep 8, 2009 at 4:21 AM, Miles Sabin <miles@milessabin.com> wrote:

On Tue, Sep 8, 2009 at 4:25 AM, Josh Suereth<joshua.suereth@gmail.com> wrote:
> With recent releases of IAM
> and the 2.8 eclipse plugin, it looks like I might have to revive the
> Eclipse-Scala-Maven project again.  I was hoping it would be unecessary due
> to things working much better without any extra plugins.   Oh well....

I was under the impression that 2.8 would improve the situation for
Maven users. Can you say what the new problems are?

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin