Difficulties creating Eclispe View in Scala

Weird. Just for fun, did you try:
class View : ViewPart {  self : ViewPart =>  ...}

Regardless, definitely looks like a huge bug in scalac's Java support. 
Sean
Not that that should work. 
On Sat, Feb 7, 2009 at 7:20 AM, David Orme <djo@coconut-palm-software.com> wrote:

I've been working on a blog entry trying to encourage Eclipse
developers toconsider Scala as a source language.  However, I'm
having trouble getting the Eclipse Scala tooling to compile a
ViewPart for me, even after lots of Google searching and two
lengthy sessions on #scala.

I get the following error the "class View extends.." line:

illegal inheritance; self-type test.View does not conform to
org.eclipse.ui.part.ViewPart's selftype org.eclipse.ui.part.ViewPart

My ViewPart code is:

package com.coconut_palm_software.scalarcp.view

import org.eclipse.swt.SWT
import org.eclipse.swt.widgets._
import org.eclipse.swt.layout._
import org.eclipse.ui.part.ViewPart

class View extends ViewPart {
 def createPartControl(parent : Composite) : Unit = {
   parent.setLayout(new FillLayout())
   val label = new Label(parent, SWT.NULL)
   label.setText("Hello, Scala")
 }
 def setFocus() = {
 }
}

Since I'm working on a blog, a detailed description of what I
did is posted there:

http://www.coconut-palm-software.com/the_new_visual_editor
/doku.php?id=java:creating_eclipse_rcp_applications_with_scala
#create_the_scala-based_eclipse_plugin

Here's a link to the complete project with the problem:

http://bitbucket.org/djo/scala-java/src/b7a9f269abd2/

(Mercurial users can just clone from http://bitbucket.org/djo/scala-java)

Additional notes:

1) I've tried creating the project as a Scala project and adding the
PDE nature in addition to creating a PDE project and ading the
Scala nature.  The only order that works at all for me is to create
the project as a Scala project and add the PDE nature.

2) I get the same behavior with the latest final release of the SDE
plugin as well as with the latest nightly build.

3) I get the same behavior on Linux and Windows.

4) This is the first major difficulty I've run into using Scala in
Eclipse.  I did a whole bunch of SWT coding last weekend using the
technique described in my blog with no problems.


Thanks in advance,

Dave Orme

I guess Sean's been doing too much C#.  He probably meant class View extends ViewPart then the rest. :)

2009/2/7 Sean McDirmid <sean.mcdirmid@gmail.com>

Weird. Just for fun, did you try:
class View : ViewPart {  self : ViewPart =>   ...}

Regardless, definitely looks like a huge bug in scalac's Java support. 
Sean
Not that that should work. 
On Sat, Feb 7, 2009 at 7:20 AM, David Orme <djo@coconut-palm-software.com> wrote:

I've been working on a blog entry trying to encourage Eclipse
developers toconsider Scala as a source language.  However, I'm
having trouble getting the Eclipse Scala tooling to compile a
ViewPart for me, even after lots of Google searching and two
lengthy sessions on #scala.

I get the following error the "class View extends.." line:

illegal inheritance; self-type test.View does not conform to
org.eclipse.ui.part.ViewPart's selftype org.eclipse.ui.part.ViewPart

My ViewPart code is:

package com.coconut_palm_software.scalarcp.view

import org.eclipse.swt.SWT
import org.eclipse.swt.widgets._
import org.eclipse.swt.layout._
import org.eclipse.ui.part.ViewPart

class View extends ViewPart {
 def createPartControl(parent : Composite) : Unit = {
   parent.setLayout(new FillLayout())
   val label = new Label(parent, SWT.NULL)
   label.setText("Hello, Scala")
 }
 def setFocus() = {
 }
}

Since I'm working on a blog, a detailed description of what I
did is posted there:

http://www.coconut-palm-software.com/the_new_visual_editor
/doku.php?id=java:creating_eclipse_rcp_applications_with_scala
#create_the_scala-based_eclipse_plugin

Here's a link to the complete project with the problem:

http://bitbucket.org/djo/scala-java/src/b7a9f269abd2/

(Mercurial users can just clone from http://bitbucket.org/djo/scala-java)

Additional notes:

1) I've tried creating the project as a Scala project and adding the
PDE nature in addition to creating a PDE project and ading the
Scala nature.  The only order that works at all for me is to create
the project as a Scala project and add the PDE nature.

2) I get the same behavior with the latest final release of the SDE
plugin as well as with the latest nightly build.

3) I get the same behavior on Linux and Windows.

4) This is the first major difficulty I've run into using Scala in
Eclipse.  I did a whole bunch of SWT coding last weekend using the
technique described in my blog with no problems.


Thanks in advance,

Dave Orme

His code snippet compiles just fine for me with command-line scalac on Mac.

--j

On Fri, Feb 6, 2009 at 4:14 PM, Sean McDirmid <sean.mcdirmid@gmail.com> wrote:

Weird. Just for fun, did you try:
class View : ViewPart {  self : ViewPart =>   ...}

Regardless, definitely looks like a huge bug in scalac's Java support. 
Sean
Not that that should work. 
On Sat, Feb 7, 2009 at 7:20 AM, David Orme <djo@coconut-palm-software.com> wrote:

I've been working on a blog entry trying to encourage Eclipse
developers toconsider Scala as a source language.  However, I'm
having trouble getting the Eclipse Scala tooling to compile a
ViewPart for me, even after lots of Google searching and two
lengthy sessions on #scala.

I get the following error the "class View extends.." line:

illegal inheritance; self-type test.View does not conform to
org.eclipse.ui.part.ViewPart's selftype org.eclipse.ui.part.ViewPart

My ViewPart code is:

package com.coconut_palm_software.scalarcp.view

import org.eclipse.swt.SWT
import org.eclipse.swt.widgets._
import org.eclipse.swt.layout._
import org.eclipse.ui.part.ViewPart

class View extends ViewPart {
 def createPartControl(parent : Composite) : Unit = {
   parent.setLayout(new FillLayout())
   val label = new Label(parent, SWT.NULL)
   label.setText("Hello, Scala")
 }
 def setFocus() = {
 }
}

Since I'm working on a blog, a detailed description of what I
did is posted there:

http://www.coconut-palm-software.com/the_new_visual_editor
/doku.php?id=java:creating_eclipse_rcp_applications_with_scala
#create_the_scala-based_eclipse_plugin

Here's a link to the complete project with the problem:

http://bitbucket.org/djo/scala-java/src/b7a9f269abd2/

(Mercurial users can just clone from http://bitbucket.org/djo/scala-java)

Additional notes:

1) I've tried creating the project as a Scala project and adding the
PDE nature in addition to creating a PDE project and ading the
Scala nature.  The only order that works at all for me is to create
the project as a Scala project and add the PDE nature.

2) I get the same behavior with the latest final release of the SDE
plugin as well as with the latest nightly build.

3) I get the same behavior on Linux and Windows.

4) This is the first major difficulty I've run into using Scala in
Eclipse.  I did a whole bunch of SWT coding last weekend using the
technique described in my blog with no problems.


Thanks in advance,

Dave Orme

it's not a bug. i'm using eclipse 3.4.0 with the latest nightly

ch.epfl.lamp.sdt.aspects (2.8.0.r17049-b20090206022915) "Scala JDT
Weaving" [Active]
ch.epfl.lamp.sdt.core (2.8.0.r17049-b20090206022920) "Scala Plugin" [Active]
scala.library (2.8.0.r17049-b20090206021002) "Scala Library" [Active]
scala.tools.nsc (2.8.0.r17049-b20090206021002) "Scala Distribution" [Active]

and it works (well at least on windows it did), checkout
http://filebin.ca/nmgxcw/scala-java.zip. just make sure you get it
before the link expires.

someone should maintain a wiki page on doing plug-in development, it was
a pain to initially get it working on my end as well.

Sean McDirmid wrote:
> Weird. Just for fun, did you try:
>
> class View : ViewPart { self : ViewPart =>
> ...
> }
>
> Regardless, definitely looks like a huge bug in scalac's Java support.
>
> Sean
>
> Not that that should work..
>
> On Sat, Feb 7, 2009 at 7:20 AM, David Orme
> > wrote:
>
> I've been working on a blog entry trying to encourage Eclipse
> developers toconsider Scala as a source language. However, I'm
> having trouble getting the Eclipse Scala tooling to compile a
> ViewPart for me, even after lots of Google searching and two
> lengthy sessions on #scala.
>
> I get the following error the "class View extends.." line:
>
> illegal inheritance; self-type test.View does not conform to
> org.eclipse.ui.part.ViewPart's selftype org.eclipse.ui.part.ViewPart
>
> My ViewPart code is:
>
> package com.coconut_palm_software.scalarcp.view
>
> import org.eclipse.swt.SWT
> import org.eclipse.swt.widgets._
> import org.eclipse.swt.layout._
> import org.eclipse.ui.part.ViewPart
>
> class View extends ViewPart {
> def createPartControl(parent : Composite) : Unit = {
> parent.setLayout(new FillLayout())
> val label = new Label(parent, SWT.NULL)
> label.setText("Hello, Scala")
> }
> def setFocus() = {
> }
> }
>
> Since I'm working on a blog, a detailed description of what I
> did is posted there:
>
> http://www.coconut-palm-software.com/the_new_visual_editor
> /doku.php?id=java:creating_eclipse_rcp_applications_with_scala
> #create_the_scala-based_eclipse_plugin
> /doku.php?id=java:creating_eclipse_rcp_applications_with_scala
> #create_the_scala-based_eclipse_plugin>
>
> Here's a link to the complete project with the problem:
>
> http://bitbucket.org/djo/scala-java/src/b7a9f269abd2/
>
> (Mercurial users can just clone from
> http://bitbucket.org/djo/scala-java)
>
> Additional notes:
>
> 1) I've tried creating the project as a Scala project and adding the
> PDE nature in addition to creating a PDE project and ading the
> Scala nature. The only order that works at all for me is to create
> the project as a Scala project and add the PDE nature.
>
> 2) I get the same behavior with the latest final release of the SDE
> plugin as well as with the latest nightly build.
>
> 3) I get the same behavior on Linux and Windows.
>
> 4) This is the first major difficulty I've run into using Scala in
> Eclipse. I did a whole bunch of SWT coding last weekend using the
> technique described in my blog with no problems.
>
>
> Thanks in advance,
>
> Dave Orme
>
>
>

On Sat, Feb 07, 2009 at 08:14:10AM +0800, Sean McDirmid wrote:
> Regardless, definitely looks like a huge bug in scalac's Java support.

Like I told him in irc, I have trouble seeing how to blame scalac here.

$ scalac -cp '/Applications/eclipse/plugins/*' OrmeView.scala
$ ls
OrmeView.scala View.class
$

Like I said on irc, I had no trouble getting this to work on my eclipse.

I did add the step of depending on the eclipse package in my osgi
manifest, and then doing a full clean.

Sent from my iPhone

On Feb 6, 2009, at 7:52 PM, Paul Phillips wrote:

> On Sat, Feb 07, 2009 at 08:14:10AM +0800, Sean McDirmid wrote:
>> Regardless, definitely looks like a huge bug in scalac's Java
>> support.
>
> Like I told him in irc, I have trouble seeing how to blame scalac
> here.
>
> $ scalac -cp '/Applications/eclipse/plugins/*' OrmeView.scala
> $ ls
> OrmeView.scala View.class
> $
>

Paul Phillips writes:
> Like I told him in irc, I have trouble seeing how to blame scalac here.
>
> $ scalac -cp '/Applications/eclipse/plugins/*' OrmeView.scala
> $ ls
> OrmeView.scala View.class

I verified that this works here too. So the same code:

a) Compiles fine from the command line
b) But not within Eclipse (for some people but not others)

Questions:

1) Could someone who got it working inside their Eclipse pull
the Mercurial repo I posted on bitbucket and see if this enables
you to reproduce the error I'm getting? For the convenience of those
who would just prefer a zip, I added a .zip archive of the project to
the repo. So you can just import the .zip file if you'd rather.

http://bitbucket.org/djo/scala-java/

2) Are there any more suggestions to try? I'd really like to figure
out a way around this so I can document the
issues and get on with my project. And finish that blog. ;-)

@Sean:

Yeah; I tried { self : ViewPart =>

It compiles then. But #createPartControl never gets called.

@all:

BTW, I'm not complaining about the help on IRC. You guys were great
and really tried to help. That's all anyone could ask; thanks.

Regards,

Dave Orme

Josh had it exactly right ...

Do what you did at the outset (ie. add the PDE nature and builders to
your .project, and add the requiredPlugins classpath container to your
.classpath). At this point I see exactly what you did: a rather
peculiar complaint about illegal inheritance.

But you should notice something odd. Despite the fact that your code
actually does require various Eclipse plugins, the required plugins
container doesn't appear because no dependencies have been inferred.
You can fix this by adding the following META-INF/MANIFEST.MF,

Bundle-SymbolicName: viewtest
Bundle-Version: 1.0.0
Bundle-Name: viewtest
Require-Bundle:
org.eclipse.core.runtime,
org.eclipse.swt,
org.eclipse.ui

and then doing a clean build.

Several open questions ...

1. Why the original "Illegal inheritance ..." issue for something
which is clearly an incomplete classpath?

2. Should these dependencies be being computed automatically? I'm so
used to maintaining MANIFEST.MF's by hand that I find it peculiar to
have to write one by hand. But it's tripped David up here, so are we
missing some Scala awareness in the PDE? In which case, any
volunteers?

Cheers,

Miles

On Sat, Feb 7, 2009 at 12:38 AM, Mohamed Bana
wrote:
> someone should maintain a wiki page on doing plug-in development, it was a
> pain to initially get it working on my end as well.

Good suggestion :-)

I'll create a page on the Scala Trac wiki and get the access controls
set appropriately ...

Cheers,

Miles

META-INF/MANIFEST.MF has to be maintained by hand for Java and Scala plug-in development, in the end its a source artifact.

It would be nice though if we had a new scala osgi bundle wizard. I am currently working on the class/trait/object wizards in order to bring them closer to their java counterparts (e.g. input fields for source folder, package, super classes/traits etc.)
I can take this one as well.

Should I give the plug-in wizard higher priority than the others?

Kind regards,
Jan

2009/2/7 Miles Sabin <miles@milessabin.com>

Josh had it exactly right ...

Do what you did at the outset (ie. add the PDE nature and builders to
your .project, and add the requiredPlugins classpath container to your
.classpath). At this point I see exactly what you did: a rather
peculiar complaint about illegal inheritance.

But you should notice something odd. Despite the fact that your code
actually does require various Eclipse plugins, the required plugins
container doesn't appear because no dependencies have been inferred.
You can fix this by adding the following META-INF/MANIFEST.MF,

 Bundle-SymbolicName: viewtest
 Bundle-Version: 1.0.0
 Bundle-Name: viewtest
 Require-Bundle:
  org.eclipse.core.runtime,
  org.eclipse.swt,
  org.eclipse.ui

and then doing a clean build.

Several open questions ...

1. Why the original "Illegal inheritance ..." issue for something
which is clearly an incomplete classpath?

2. Should these dependencies be being computed automatically? I'm so
used to maintaining MANIFEST.MF's by hand that I find it peculiar to
have to write one by hand. But it's tripped David up here, so are we
missing some Scala awareness in the PDE? In which case, any
volunteers?

Cheers,


Miles

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

On Sat, Feb 7, 2009 at 12:32 PM, Jan Lohre wrote:
> I am currently working on the class/trait/object wizards in order to bring them
> closer to their java counterparts (e.g. input fields for source folder,
> package, super classes/traits etc.)

Fantastic!

But, *please* take a very close look at how this is being done in the
very latest release of the AspectJ development tools (AJDT) ... using
aspects we can most likely reuse almost all of the Java wizards (see
the way the AJDT reuses the Java wizards for creating new advice).

Cheers,

Miles

Thanks for the hint, I wouldn't have thought reusing the uis would have been possible.

Just to make sure I understand correctly, I should have a look at aspect wizards how they reuse java wizards?

One problem I see is that I never used aspects so it adds another technology to my learning stack (I have to admit I am still at learning-level in scala)
Can you give me a hint where to look up usage of aspects together with scala coding?

Just another note: I am not sure the ui perfectly fits for scala (e.g. modifiers public and default which have different meanings in java than in scala)
Having had another look it seems everything is mappable from java to scala (public->default, default->protected[thispackage], for enclosed types: static->companion object) so I will try to go this path, but it'll take a bit longer.

Kind regards,
Jan

2009/2/7 Miles Sabin <miles@milessabin.com>

On Sat, Feb 7, 2009 at 12:32 PM, Jan Lohre <jan.lohre@googlemail.com> wrote:
> I am currently working on the class/trait/object wizards in order to bring them
> closer to their java counterparts (e.g. input fields for source folder,
> package, super classes/traits etc.)

Fantastic!

But, *please* take a very close look at how this is being done in the
very latest release of the AspectJ development tools (AJDT) ... using
aspects we can most likely reuse almost all of the Java wizards (see
the way the AJDT reuses the Java wizards for creating new advice).

Cheers,


Miles

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

I just imported ajdt.core and ui as source from the target platform and get a lot off error markers(332) so I seem to be missing something.

Just an example:
...
int mdf = proceed();
...

This has an error marker complaining that there is no such method proceed() in AJNewTypeWizardPage while proceed is (I assume for good reason) highlighted as keyword. I tried cleaning the projects and even restarted eclipse which both do not resolve the issues.

From a glimpse look its only *.aj files so AspectJ and JDT seem to get in conflict.

Kind regards,
Jan

2009/2/7 Jan Lohre <jan.lohre@googlemail.com>

Thanks for the hint, I wouldn't have thought reusing the uis would have been possible.

Just to make sure I understand correctly, I should have a look at aspect wizards how they reuse java wizards?

One problem I see is that I never used aspects so it adds another technology to my learning stack (I have to admit I am still at learning-level in scala)
Can you give me a hint where to look up usage of aspects together with scala coding?

Just another note: I am not sure the ui perfectly fits for scala (e.g. modifiers public and default which have different meanings in java than in scala)
Having had another look it seems everything is mappable from java to scala (public->default, default->protected[thispackage], for enclosed types: static->companion object) so I will try to go this path, but it'll take a bit longer.

Kind regards,
Jan

2009/2/7 Miles Sabin <miles@milessabin.com>

On Sat, Feb 7, 2009 at 12:32 PM, Jan Lohre <jan.lohre@googlemail.com> wrote:
> I am currently working on the class/trait/object wizards in order to bring them
> closer to their java counterparts (e.g. input fields for source folder,
> package, super classes/traits etc.)

Fantastic!

But, *please* take a very close look at how this is being done in the
very latest release of the AspectJ development tools (AJDT) ... using
aspects we can most likely reuse almost all of the Java wizards (see
the way the AJDT reuses the Java wizards for creating new advice).

Cheers,


Miles

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

Solved, I should have looked into the .project file before complaining ;-)

For those interested: Import from Target Platform creates plain PDE projects (so its kind of missing PDE support for AspectJ plug-ins), maybe I should report it to the AJDT developers so they can create aspects for said import wizard.

Kind regards,
Jan

2009/2/7 Jan Lohre <jan.lohre@googlemail.com>

I just imported ajdt.core and ui as source from the target platform and get a lot off error markers(332) so I seem to be missing something.

Just an example:
...
int mdf = proceed();
...

This has an error marker complaining that there is no such method proceed() in AJNewTypeWizardPage while proceed is (I assume for good reason) highlighted as keyword. I tried cleaning the projects and even restarted eclipse which both do not resolve the issues.

From a glimpse look its only *.aj files so AspectJ and JDT seem to get in conflict.

Kind regards,
Jan

2009/2/7 Jan Lohre <jan.lohre@googlemail.com>

Thanks for the hint, I wouldn't have thought reusing the uis would have been possible.

Just to make sure I understand correctly, I should have a look at aspect wizards how they reuse java wizards?

One problem I see is that I never used aspects so it adds another technology to my learning stack (I have to admit I am still at learning-level in scala)
Can you give me a hint where to look up usage of aspects together with scala coding?

Just another note: I am not sure the ui perfectly fits for scala (e.g. modifiers public and default which have different meanings in java than in scala)
Having had another look it seems everything is mappable from java to scala (public->default, default->protected[thispackage], for enclosed types: static->companion object) so I will try to go this path, but it'll take a bit longer.

Kind regards,
Jan

2009/2/7 Miles Sabin <miles@milessabin.com>

On Sat, Feb 7, 2009 at 12:32 PM, Jan Lohre <jan.lohre@googlemail.com> wrote:
> I am currently working on the class/trait/object wizards in order to bring them
> closer to their java counterparts (e.g. input fields for source folder,
> package, super classes/traits etc.)

Fantastic!

But, *please* take a very close look at how this is being done in the
very latest release of the AspectJ development tools (AJDT) ... using
aspects we can most likely reuse almost all of the Java wizards (see
the way the AJDT reuses the Java wizards for creating new advice).

Cheers,


Miles

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

Slightly lower-level:  It would be nice to have a version of the scala compiler that was OSGi-Aware so that we get warnings at compile time when we import classes that are not exported, etc.  I was debating tackling this.   I had spent a few days doing research into PDE integration for the sclaa plugin.  I'm sure most of this has changed since I looked (with the new AJDT stuff), but here's my original captured list of data: http://code.google.com/p/esmi/wiki/PageName.  To me the biggest win would be integrating into the "Organize Manifest Processor".  After that would be adding pde-like quick fixes for "This class is not imported in your manifest, would you like to add it?"

Infrastructure-wise, when will we be able to have multiple plugins/features for Eclipse?  I really think the PDE integration stuff should probably be a separate plugin/feature from the core scala stuff.  I'm willing to keep placing everythign in the same plugin, but I'm not sure it's the best of ideas.

If it helps, I've recently started using Tycho:  http://www.sonatype.com//people/2008/11/building-eclipse-plugins-with-maven-tycho/  to build a project with about 8 plugins and 3 features.   It's pretty easy to get set-up, however I still have to work out the kinks of compiling a scala project.  It also automatically generates update sites with p2 data, and pulls information on the project by default from the eclipse .project and build.settings files (which are used when eclipse does its own PDE builds).  I must say, it's very nice for doing multiple-plugin development from a single repository directory as you can nest the plugins in sub-directories.  I think this would put our build process *much* closer to the eclipse environment.

I know my biggest frustration in working on the plugin is setting up my eclipse environment again after x weeks of inactivity.  It usually doesn't just work out of the box, and I haven't been able to get the plugin dogfooding  well in windows for several months now (the plugin works fine for all projects except itself).  These are all barriers to contributors that hopefully we can reduce as time goes on.  I''ve tried to contribute patches where I could figure out what the issues are, but some of these bugs are very hard to track down.

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

Josh had it exactly right ...

Do what you did at the outset (ie. add the PDE nature and builders to
your .project, and add the requiredPlugins classpath container to your
.classpath). At this point I see exactly what you did: a rather
peculiar complaint about illegal inheritance.

But you should notice something odd. Despite the fact that your code
actually does require various Eclipse plugins, the required plugins
container doesn't appear because no dependencies have been inferred.
You can fix this by adding the following META-INF/MANIFEST.MF,

 Bundle-SymbolicName: viewtest
 Bundle-Version: 1.0.0
 Bundle-Name: viewtest
 Require-Bundle:
  org.eclipse.core.runtime,
  org.eclipse.swt,
  org.eclipse.ui

and then doing a clean build.

Several open questions ...

1. Why the original "Illegal inheritance ..." issue for something
which is clearly an incomplete classpath?

2. Should these dependencies be being computed automatically? I'm so
used to maintaining MANIFEST.MF's by hand that I find it peculiar to
have to write one by hand. But it's tripped David up here, so are we
missing some Scala awareness in the PDE? In which case, any
volunteers?

Cheers,


Miles

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

On Sat, Feb 7, 2009 at 5:03 PM, Josh Suereth wrote:
> Infrastructure-wise, when will we be able to have multiple plugins/features
> for Eclipse? I really think the PDE integration stuff should probably be a
> separate plugin/feature from the core scala stuff. I'm willing to keep
> placing everythign in the same plugin, but I'm not sure it's the best of
> ideas.

I've no objection to doing this, but on the other hand I can't really
see all that much to be gained from doing it either. The current split
into scala-plugin and scala-plugin-aspects is motivated by the fact
that Scala and AspectJ can't currently be mixed in a single project,
but if it had been I would probably have kept them as one.

But I'm open to alternatives ... what would be the benefits of
splitting the project further?

Cheers,

Miles

Besides separation of concerns, and modularization, you could also do
access controls where developer X can only commit to plugin Y.

Also it gives a place for things not directly related to scala core
that could optionally be installed, e.g. The maven integration could
be an optionally installed feature from the scala update site. As
eclipse has myriads of plugins, a lot of projects try to keep the
"core" footprint small while providing "integration" features.

Another reason is boot time. With lazy-start bundles you can defer
some startup time until necessary (although it causes a first-time lag
on some actions). However in some cases features are never used by
developers, and therefore *should* be lazy started to reduce memory
footprint.

I agree that too much complexity is unecessary, and I don't want to
add any if we don't gain something usefull from it. I do think an
*easy* process of adding plugins to the SDT is healthy and necessary
in the near future.

You've done a lot of great work on the build process (otherwise I
would have been unable to contribute at all). I just want to make
sure we don't stop improving the code (BTW the aspect stuff works
great!).

- Josh

On Feb 8, 2009, at 5:39 AM, Miles Sabin wrote:

> On Sat, Feb 7, 2009 at 5:03 PM, Josh Suereth
> wrote:
>> Infrastructure-wise, when will we be able to have multiple plugins/
>> features
>> for Eclipse? I really think the PDE integration stuff should
>> probably be a
>> separate plugin/feature from the core scala stuff. I'm willing to
>> keep
>> placing everythign in the same plugin, but I'm not sure it's the
>> best of
>> ideas.
>
> I've no objection to doing this, but on the other hand I can't really
> see all that much to be gained from doing it either. The current split
> into scala-plugin and scala-plugin-aspects is motivated by the fact
> that Scala and AspectJ can't currently be mixed in a single project,
> but if it had been I would probably have kept them as one.
>
> But I'm open to alternatives ... what would be the benefits of
> splitting the project further?
>
> Cheers,
>
>
> Miles
>

On Sun, Feb 8, 2009 at 1:47 PM, Josh Suereth wrote:
> Besides separation of concerns, and modularization,

Well, yes, but do we really need this at the level of granularity of
SVN modules and OSGi bundles?

> you could also do access controls where developer X can only commit to plugin Y.

Wow! I would love to have the problem of having such a huge pool of
committers to the plugin that I'd want differential access control!
;-)

> Also it gives a place for things not directly related to scala core that
> could optionally be installed, e.g. The maven integration could be an
> optionally installed feature from the scala update site. As eclipse has
> myriads of plugins, a lot of projects try to keep the "core" footprint
> small while providing "integration" features.

OK, this is a better example ... genuinely optional/orthogonal
components do deserve their own modules/bundles.

> Another reason is boot time. With lazy-start bundles you can defer some
> startup time until necessary (although it causes a first-time lag on some
> actions). However in some cases features are never used by developers, and
> therefore *should* be lazy started to reduce memory footprint.

I agree that there's too much startup overhead at the moment, but I
think there's a lot more that can be done within the existing
structure before splitting starts to offer anything significant.

> I agree that too much complexity is unecessary, and I don't want to add any
> if we don't gain something usefull from it. I do think an *easy* process of
> adding plugins to the SDT is healthy and necessary in the near future.

I'm not really objecting all that hard ... it's just that there's so
much to do on the plugin that I'd rather we didn't waste time on
marginally useful busy-work. Adding new functionality via additional
bundles (eg. the maven stuff you mentioned above) seems like a good
idea tho'. Any significant reorganization of the layout of the main
plugin should probably wait until there's an opportunity to do a major
refactoring of the code at which point moving stuff around in SVN and
rearranging bundles will be a relatively minor part of the process.

> You've done a lot of great work on the build process (otherwise I would have
> been unable to contribute at all). I just want to make sure we don't stop
> improving the code (BTW the aspect stuff works great!).

:-)

Cheers,

Miles

Hi Miles,

Quoting myself:
>Just to make sure I understand correctly, I should have a look at aspect wizards how they reuse java wizards?

>One problem I see is that I never used aspects so it adds another technology to my learning stack (I have to admit I am still at learning-level in scala)
>Can you give me a hint where to look up usage of aspects together with scala coding?

Having had a look at AJDT the first question somehow answered itself with a yes.
But the second did not yet.

I am getting a bit tired to repost my own questions as they stay without response.

Kind regards,
Jan


2009/2/7 Jan Lohre <jan.lohre@googlemail.com>

Thanks for the hint, I wouldn't have thought reusing the uis would have been possible.

Just to make sure I understand correctly, I should have a look at aspect wizards how they reuse java wizards?

One problem I see is that I never used aspects so it adds another technology to my learning stack (I have to admit I am still at learning-level in scala)
Can you give me a hint where to look up usage of aspects together with scala coding?

Just another note: I am not sure the ui perfectly fits for scala (e.g. modifiers public and default which have different meanings in java than in scala)
Having had another look it seems everything is mappable from java to scala (public->default, default->protected[thispackage], for enclosed types: static->companion object) so I will try to go this path, but it'll take a bit longer.

Kind regards,
Jan

2009/2/7 Miles Sabin <miles@milessabin.com>

On Sat, Feb 7, 2009 at 12:32 PM, Jan Lohre <jan.lohre@googlemail.com> wrote:
> I am currently working on the class/trait/object wizards in order to bring them
> closer to their java counterparts (e.g. input fields for source folder,
> package, super classes/traits etc.)

Fantastic!

But, *please* take a very close look at how this is being done in the
very latest release of the AspectJ development tools (AJDT) ... using
aspects we can most likely reuse almost all of the Java wizards (see
the way the AJDT reuses the Java wizards for creating new advice).

Cheers,


Miles

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

On Tue, Feb 10, 2009 at 8:32 PM, Jan Lohre wrote:
> Can you give me a hint where to look up usage of aspects together with
> scala coding?

Scala doesn't directly mix with AspectJ: you have to define hooks into
the JDT using AspectJ and Java ... the new project
scala-plugin-aspects gives an example of just that (currently it just
modifies the Java builders behaviour to cooperate nicely with the
Scala builder).

I'd expect you to be able to take something similar to the code in the
AJDT which extends the JDTs wizards to support aspects and adapt it
for Scala classes/objects/traits and add that to the
scala-plugin-aspects project.

Cheers,

Miles