Heads up: Equinox Aspects-based Eclipse plugin build now on trunk

Congratulations!!!! I look forward to using and developing to this!

-Josh

On Thu, Feb 5, 2009 at 10:26 AM, Miles Sabin <miles@milessabin.com> wrote:

Hi folks,

The long promised Equinox Aspects-based approach to JDT integration
has just landed on trunk and with any luck should be available from
the nightly build update site from tomorrow. For the impatient,
there's also an update site here,

 http://www.milessabin.com/scala-aspects

There won't be a huge amount of visible difference from what you can
already see in the current release. Nevertheless a number of niggling
bugs and misfeatures are dealt with by this drop. In particular,

* You no longer need project-specific Java builder settings to allow
correct compilation of a Scala project. This means that the .settings
directories which previously appeared in every Scala project can be
removed (assuming they're not needed for any other purpose). I believe
this will make life easier for people working with Maven.

* The JDT is now aware of Scala objects and traits (previously it was
only aware of Scala classes). This means that a number of spurious
errors which were reported in mixed Scala/Java projects against Java
code which referenced Scala objects will be eliminated. It also means
that Scala objects and traits will be accessible from the JDT's "Open
Type" dialog.

* Moving and renaming Scala files is now possible in the same way as
Java. Note that this isn't quite a rename refactoring yet, but with
any luck that should follow soon.

Most likely a number of other JDT driven features will also have
started working (or started working closer to correctly). Over the
next couple of days I will be going through the current open bugs
closing the ones which have been fixed as a side effect of this change
... any help on this (particularly if it's your (least) favourite bug)
would be very much appreciated.

As you might have seen in my other mail I've also started a Scala
Eclipse plugin FAQ here,

 https://lampsvn.epfl.ch/trac/scala/wiki/EclipsePluginFAQ

Please pay close attention to the "Installation Issues" section for
trunk. I've also updated the plugin hacking document here,

 http://lampsvn.epfl.ch/trac/scala/wiki/EclipsePlugin

and that should be a reliable guide for the current state of play.

As ever any and all contributions would be most welcome.

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

This is great!!! Well done Miles!!!

On Thu, Feb 5, 2009 at 5:26 PM, Miles Sabin <miles@milessabin.com> wrote:

Hi folks,

The long promised Equinox Aspects-based approach to JDT integration
has just landed on trunk and with any luck should be available from
the nightly build update site from tomorrow. For the impatient,
there's also an update site here,

 http://www.milessabin.com/scala-aspects

There won't be a huge amount of visible difference from what you can
already see in the current release. Nevertheless a number of niggling
bugs and misfeatures are dealt with by this drop. In particular,

* You no longer need project-specific Java builder settings to allow
correct compilation of a Scala project. This means that the .settings
directories which previously appeared in every Scala project can be
removed (assuming they're not needed for any other purpose). I believe
this will make life easier for people working with Maven.

* The JDT is now aware of Scala objects and traits (previously it was
only aware of Scala classes). This means that a number of spurious
errors which were reported in mixed Scala/Java projects against Java
code which referenced Scala objects will be eliminated. It also means
that Scala objects and traits will be accessible from the JDT's "Open
Type" dialog.

* Moving and renaming Scala files is now possible in the same way as
Java. Note that this isn't quite a rename refactoring yet, but with
any luck that should follow soon.

Most likely a number of other JDT driven features will also have
started working (or started working closer to correctly). Over the
next couple of days I will be going through the current open bugs
closing the ones which have been fixed as a side effect of this change
... any help on this (particularly if it's your (least) favourite bug)
would be very much appreciated.

As you might have seen in my other mail I've also started a Scala
Eclipse plugin FAQ here,

 https://lampsvn.epfl.ch/trac/scala/wiki/EclipsePluginFAQ

Please pay close attention to the "Installation Issues" section for
trunk. I've also updated the plugin hacking document here,

 http://lampsvn.epfl.ch/trac/scala/wiki/EclipsePlugin

and that should be a reliable guide for the current state of play.

As ever any and all contributions would be most welcome.

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

--
 __~O
-\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

Hi Miles,

This is exciting!   I'm looking forward to getting back into Eclipse.

On Thu, Feb 5, 2009 at 7:26 AM, Miles Sabin <miles@milessabin.com> wrote:

* You no longer need project-specific Java builder settings to allow
correct compilation of a Scala project. This means that the .settings
directories which previously appeared in every Scala project can be
removed (assuming they're not needed for any other purpose). I believe
this will make life easier for people working with Maven.

I'm not sure I understand this correctly.   Are there any changes to the <projectDescription> "specification" that documented here:
http://www.scala-lang.org/node/94

I maintain the Buildr Eclipse project generation and I'd like to update the code if there are any necessary changes there.

Our current specs cover the following:

it 'should have Scala nature before Java nature'
it 'should have Scala build command and no Java build command'

it 'should have SCALA_CONTAINER before JAVA_CONTAINER'

alex

On Thu, Feb 5, 2009 at 4:34 PM, Alex Boisvert wrote:
> This is exciting! I'm looking forward to getting back into Eclipse.

Excellent! :-)

>> * You no longer need project-specific Java builder settings to allow
>> correct compilation of a Scala project. This means that the .settings
>> directories which previously appeared in every Scala project can be
>> removed (assuming they're not needed for any other purpose). I believe
>> this will make life easier for people working with Maven.
>
> I'm not sure I understand this correctly. Are there any changes to the
> "specification" that documented here:
> http://www.scala-lang.org/node/94

Yes, for trunk builds *only* the final bullet point there "The
per-project properties should be set as follows, ..." no longer
applies. Setting the Java settings as described there are unlikely to
do any harm on trunk, but they're no longer necessary.

Just to emphasize ... if you're working with the 2.7.x branch (and
that includes 2.7.3 now and 2.7.4 in the future) you should keep those
project specific settings as they are.

> I maintain the Buildr Eclipse project generation and I'd like to update the
> code if there are any necessary changes there.
>
> Our current specs cover the following:
>
> it 'should have Scala nature before Java nature'
> it 'should have Scala build command and no Java build command'
>
> it 'should have SCALA_CONTAINER before JAVA_CONTAINER'

That's correct for trunk, but quite possibly insufficient for 2.7.3/4:
if a user attempts to work in Eclipse with a project that *doesn't*
have the project specific settings configured as decscribed then
they'll see the old favourite "no classfiles generated and all my
*.scala files copied to the output directory".

Cheers,

Miles

Ok, thanks for the clarifications. 

(I had forgotten about this project-specific settings business; it's not currently handled by the Buildr Eclipse plugin... ooops!!  ... it may have been the cause of some of my previous complaints... my apologies!).

alex


On Thu, Feb 5, 2009 at 8:45 AM, Miles Sabin <miles@milessabin.com> wrote:

On Thu, Feb 5, 2009 at 4:34 PM, Alex Boisvert <boisvert@intalio.com> wrote:
> This is exciting!   I'm looking forward to getting back into Eclipse.

Excellent! :-)

>> * You no longer need project-specific Java builder settings to allow
>> correct compilation of a Scala project. This means that the .settings
>> directories which previously appeared in every Scala project can be
>> removed (assuming they're not needed for any other purpose). I believe
>> this will make life easier for people working with Maven.
>
> I'm not sure I understand this correctly.   Are there any changes to the
> <projectDescription> "specification" that documented here:
> http://www.scala-lang.org/node/94

Yes, for trunk builds *only* the final bullet point there "The
per-project properties should be set as follows, ..." no longer
applies. Setting the Java settings as described there are unlikely to
do any harm on trunk, but they're no longer necessary.

Just to emphasize ... if you're working with the 2.7.x branch (and
that includes 2.7.3 now and 2.7.4 in the future) you should keep those
project specific settings as they are.

> I maintain the Buildr Eclipse project generation and I'd like to update the
> code if there are any necessary changes there.
>
> Our current specs cover the following:
>
> it 'should have Scala nature before Java nature'
> it 'should have Scala build command and no Java build command'
>
> it 'should have SCALA_CONTAINER before JAVA_CONTAINER'

That's correct for trunk, but quite possibly insufficient for 2.7.3/4:
if a user attempts to work in Eclipse with a project that *doesn't*
have the project specific settings configured as decscribed then
they'll see the old favourite "no classfiles generated and all my
*.scala files copied to the output directory".

Cheers,


Miles

--
Miles Sabin
tel:    +44 (0)1273 720 779
mobile: +44 (0)7813 944 528
skype:  milessabin

> There won't be a huge amount of visible difference from what you can
> already see in the current release. Nevertheless a number of niggling
> bugs and misfeatures are dealt with by this drop. In particular,

Let me disagree on that, the JDT integration is a major feature!

Erik.

Miles Sabin wrote:
>
> The long promised Equinox Aspects-based approach to JDT integration
> has just landed on trunk and with any luck should be available from
> the nightly build update site from tomorrow.
>

1. Installed from the nightly trunk update site onto Eclipse 3.4.1 yesterday
and so far it has worked beautifully. The improvement since the the previous
release I installed (2.7.3 final) is simply stunning. :jumping:

2. I did some reading this "Aspects-based approach" (thanks to
[http://blog.juma.me.uk/2009/02/14/scala-plugin-snapshot/]), and in
particular, the way it allows the scala plugin to provide its own
Scala-specific ICompilationUnit to JDT. This is a very impressive piece of
software technology, that perhaps still has much more fruit to bear.

One question: Equinox Aspects is
[http://www.eclipse.org/equinox/incubator/aspects/] is listed as in
incubator stage, milestone 5 was Jan 30. How is is working in my standard
3.4.1 build?

-Ben

On Wed, Feb 18, 2009 at 11:06 PM, Ben Hutchison wrote:
> 1. Installed from the nightly trunk update site onto Eclipse 3.4.1 yesterday
> and so far it has worked beautifully. The improvement since the the previous
> release I installed (2.7.3 final) is simply stunning. :jumping:

Thanks for the vote of confidence! :-)

> 2. I did some reading this "Aspects-based approach" (thanks to
> [http://blog.juma.me.uk/2009/02/14/scala-plugin-snapshot/]), and in
> particular, the way it allows the scala plugin to provide its own
> Scala-specific ICompilationUnit to JDT. This is a very impressive piece of
> software technology, that perhaps still has much more fruit to bear.

Absolutely ... you ain't seen nothing yet ...

> One question: Equinox Aspects is
> [http://www.eclipse.org/equinox/incubator/aspects/] is listed as in
> incubator stage, milestone 5 was Jan 30. How is is working in my standard
> 3.4.1 build?

Because it's installed as a side-effect of the Scala plugin install.

Cheers,

Miles