Morped modules-scala-console to scala code

[og0815]

To get warmed up, I morphed the scala-console module to scala code.
I keept the Action and the TopComponent in Java, because I intend to convert them to nb7xx style with annotations, removing the need for the xml files.
(Netbeans Annotations at Scala code seam to be ignored)

[dcaoyuan]

(Netbeans Annotations at Scala code seam to be ignored)
Yes. That's why I keep use xml instead of nb7xx annotations.

Welcome to board.

[dcaoyuan]

Hi,

I merged your code. Please give me your public key, I'll add you as the
developer.

-Caoyuan

On Sun, Mar 25, 2012 at 10:14 PM, Oliver Günther <
reply@reply.github.com

wrote:

To get warmed up, I morphed the scala-console module to scala code.
I keept the Action and the TopComponent in Java, because I intend to
convert them to nb7xx style with annotations, removing the need for the xml
files.
(Netbeans Annotations at Scala code seam to be ignored)

You can merge this Pull Request by running:

git pull https://github.com/og0815/nbscala master

Or you can view, comment on it, or merge it online at:

#36

-- Commit Summary --

• Morphed the Scala Console to Scala

-- File Changes --

M README.md (154)
M pom.xml (532)
M scala.console/pom.xml (232)
M
scala.console/src/main/java/org/netbeans/modules/scala/console/ScalaConsoleTopComponent.java
(985)
D
scala.console/src/main/java/org/netbeans/modules/scala/console/ScalaExecution.java
(368)
D
scala.console/src/main/java/org/netbeans/modules/scala/console/readline/FileNameCompletor.java
(137)
D
scala.console/src/main/java/org/netbeans/modules/scala/console/readline/History.java
(255)
D
scala.console/src/main/java/org/netbeans/modules/scala/console/readline/TextAreaReadline.java
(354)
A
scala.console/src/main/scala/org/netbeans/modules/scala/console/ScalaExecution.scala
(349)
R
scala.console/src/main/scala/org/netbeans/modules/scala/console/readline/Completor.scala
(15)
R
scala.console/src/main/scala/org/netbeans/modules/scala/console/readline/ConsoleLineReader.scala
(36)
A
scala.console/src/main/scala/org/netbeans/modules/scala/console/readline/FileNameCompletor.scala
(124)
A
scala.console/src/main/scala/org/netbeans/modules/scala/console/readline/History.scala
(216)
A
scala.console/src/main/scala/org/netbeans/modules/scala/console/readline/TextAreaReadline.scala
(294)

-- Patch Links --

https://github.com/dcaoyuan/nbscala/pull/36.patch
https://github.com/dcaoyuan/nbscala/pull/36.diff

---

Reply to this email directly or view it on GitHub:
#36

[jglick]

Regarding NetBeans layer-generating annotations in Scala source: not sure if it would even be possible for scalac to run JSR 269-compliant processors. For groovyc I think it would be possible, as I commented in GROOVY-3361, but that is a source language much closer to Java, with mostly similar constructs.

[dcaoyuan]

Is the main task that a partial mapper which maps annotations at scalal AST
to java? if so, I can write it.

-Caoyuan

On Thu, Apr 5, 2012 at 10:03 PM, jglick <
reply@reply.github.com

wrote:

Regarding NetBeans layer-generating annotations in Scala source: not sure
if it would even be possible for scalac to run JSR 269-compliant
processors. For groovyc I think it would be possible, as I commented in
GROOVY-3361, but that is a
source language much closer to Java, with mostly similar constructs.

---

Reply to this email directly or view it on GitHub:
#36 (comment)

[jglick]

No, it is more than that; an implementation of javax.lang.model and javax.annotation.processing would be needed. Parts of the Scala AST which do not clearly correspond to Java language constructs (with comparable runtime behavior at the JVM level) would have to be omitted. Whether the result would really work naturally, I do not know.

[dcaoyuan]

Thanks for the information, I'll think about it.

-Caoyuan

On Fri, Apr 6, 2012 at 1:50 AM, jglick <
reply@reply.github.com

wrote:

No, it is more than that; an implementation of javax.lang.model and
javax.annotation.processing would be needed. Parts of the Scala AST which
do not clearly correspond to Java language constructs (with comparable
runtime behavior at the JVM level) would have to be omitted. Whether the
result would really work naturally, I do not know.

---

Reply to this email directly or view it on GitHub:
#36 (comment)

[og0815]

For the time being, I would suggest, to keep the annotated parts in java. Most of the time these are user interfaces. And I don't think anyone is interested in hand crafting these.

[dcaoyuan]

Agree.

-Caoyuan

On Tue, Apr 10, 2012 at 12:55 AM, Oliver Günther <
reply@reply.github.com

wrote:

For the time being, I would suggest, to keep the annotated parts in java.
Most of the time these are user interfaces. And I don't think anyone is
interested in hand crafting these.

---

Reply to this email directly or view it on GitHub:
#36 (comment)