- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Scala Compiler Plugin Development Questions
Thu, 2011-11-10, 21:44
Hi,
reading [1] i learn that you only can add ad-hoc plugins (the one in development) using the -XPlugin:<jar> containing at least the descriptors. Code can be contributed in the launch classpath next to anything else necessary to run the compiler.So that to me looks like the scala compiler plugin model does not have any sandboxing (classpath wise). Is this correct ?
Now, while this has its drawbacks in "production" it probably helps at development time. But then its not optimal to add the descriptor xml as a packed as jar format only. It kind of feels unnecessary. If its all slapped into one spaghetti classpath (read below for some reasoning), why not auto detect those descriptors and/or provide a way to just point the compiler to descriptors ? (Reminder: i'm not saying i totally like this unsandboxed plugin model yet)
As an explanation, i kind of like the plugin support directly in the compiler in order to leverage the more meaningful & rich source semantics that go-away once its compiled down to bytecode. To me, this is another benefit that scala providers over naked java.I am trying to figure out pros & cons of using compiler plugins to extract richer meta data that is getting used later in the build process (for example when creating assemblies that encapsulate some functionality). So maybe someone here wants to stop me telling the scala compiler plugin support "is ancient science that should not be used" or "wait here's the cool sandboxing model that currently sits in branch X and will come in scala 2.10". Just curious.
Thanks for some insight,Toni
[1] http://www.scala-lang.org/node/140
--http://tonimenzel.com - http://www.ops4j.org
reading [1] i learn that you only can add ad-hoc plugins (the one in development) using the -XPlugin:<jar> containing at least the descriptors. Code can be contributed in the launch classpath next to anything else necessary to run the compiler.So that to me looks like the scala compiler plugin model does not have any sandboxing (classpath wise). Is this correct ?
Now, while this has its drawbacks in "production" it probably helps at development time. But then its not optimal to add the descriptor xml as a packed as jar format only. It kind of feels unnecessary. If its all slapped into one spaghetti classpath (read below for some reasoning), why not auto detect those descriptors and/or provide a way to just point the compiler to descriptors ? (Reminder: i'm not saying i totally like this unsandboxed plugin model yet)
As an explanation, i kind of like the plugin support directly in the compiler in order to leverage the more meaningful & rich source semantics that go-away once its compiled down to bytecode. To me, this is another benefit that scala providers over naked java.I am trying to figure out pros & cons of using compiler plugins to extract richer meta data that is getting used later in the build process (for example when creating assemblies that encapsulate some functionality). So maybe someone here wants to stop me telling the scala compiler plugin support "is ancient science that should not be used" or "wait here's the cool sandboxing model that currently sits in branch X and will come in scala 2.10". Just curious.
Thanks for some insight,Toni
[1] http://www.scala-lang.org/node/140
--http://tonimenzel.com - http://www.ops4j.org
