0

以前は、JavaScript 用の Java エンジン - rhino - に疑似ファイル システムを提供しようとしていましたが、成功しました ( jszip maven プラグイン) 。

私は今、SASSコンパイラに注目しています

JRuby を Maven プラグインに統合し、SASS コンパイラを正常に呼び出すことができるようになったので、最後のステップ (ハックランドから保守可能なコードへの大幅なリファクタリングの前) は、JRuby が認識するパスを偽造することです。

私の感じでは、Rhino のトリック (Rhino スコープで java.io.File クラス アダプターを再マップする場所) を再利用することはできないと思います。なぜなら、Ruby には一般に、異なる Ruby VM 間の違いを修正するためのアダプター レイヤーがないからです。

それで、次に考えたのはモンキーパッチでした...しかし、それがどれほど大きな仕事になるかはわかりません...

JavaScriptjava.io.Fileを使っjava.io.FileReaderて、、、、、java.io.FileWriterjava.io.FileInputStreamjava.io.FileOutputStream

Rubyランタイムでモンキーパッチをどれだけ必要としますか...または、ASMベースの書き換えクラスローダーを使用して、JRuby自体の下から敷物を引っ張る方がよいでしょうか(宝石などをロードするための正当なファイルの使用を壊す危険があります)

4

1 に答える 1

1

SASSコンパイラに関する私の特定の問題に対する答えですが、JRubyに偽のファイルシステムを与えるためにモンキーパッチを適用するために何をすべきかという一般的な質問に対する答えではありません。

Sassには、解決とファイルSass::Importer::Baseの基本クラスであるという概念があることがわかりました。したがって、必要なのは、仮想ファイルシステムに委任する独自の実装を作成し、渡されるオプションを構成して、デフォルトのファイルシステムベースのインポーターがインポーターの実装に置き換えられるようにすることだけです。.scss.sassSass::Engine.new

おそらく、 BootstrapがスタンドアロンであるLESSサポートのテスト経験とは対照的に、Compassに依存しているために、Foundation3をコンパイルしようとして問題が発生したようです。

アップデート

ASMベースの書き換えクラスローダーに関して。おそらく、そのアプローチの秘訣は、AspectCを使用してJRubyランタイムでそれらのクラスのみを変更することです。つまり、クラスがRubyObjectを拡張する場合にのみアスペクトを適用します。これにより、組み込みVMに偽のファイルシステムを提供しながら、RubyソースコードをロードするJRubyの正当なニーズが維持されます。

モンキーパッチに関しては、モンキーパッチが確実に保持されるようにするために、RubyのファイルAPIが提供するすべての同等のメソッドを埋める作業がたくさんあるようです。特に、モンキーパッチの正確なフットプリントがわからない場合はそうです。 SASSコンパイラが使用するAPI。

したがって、完全な答えは次のようになります。「使用するライブラリは、仮想ファイルシステムにフィードできるようにするための優れた抽象化を提供するため、モンキーパッチやASMの書き換えは行いたくない」

于 2013-01-31T16:43:52.723 に答える