Jdbi: StringTemplate4のサポートを推奨しないおよび非推奨

StringTemplateプロジェクトが非アクティブであるというドキュメントの通知から始めましょう。

他のプロジェクトメンバーに、JdbiのST統合を非推奨にする問題について検討させます。 個人的には、少なくともしばらくはサポートを続けるべきだと思います。 そもそもST4のサポートを始めたばかりです。

代替案が必要だと思います。 SQL用の複雑なテンプレートを作成する方法がないのはダメです。 異なるテンプレート間でSQLビットとパーツを共有できる必要があり、一般的なものをテンプレートメソッドに分解できる必要があります。 私にとって、stringtemplateを削除すると、別の代替フレームワークを探すようになります。 そうでなければ、私は多くの重複を伴​​うSQLファイルを作成することを余儀なくされるでしょう。

NOTICE追加しましょう。 実行可能な代替品ができたら、非推奨にすることができます。

jdbiにうまく収まるお気に入りのテンプレートエンジンを持っている人はいますか？ 私はmustacheを少し使用しましたが、それは問題ありませんでしたが、専門家からはほど遠いです...

@jarlahに感謝し

残念ながら、StringTemplateがアップストリームで無視されていますが、人々がそれを使用して機能している限り、サポートを撤回する理由はありません。

私が働いているFreeMarkerにはかなり満足しています。 口ひげも良い選択肢です。

@jarlahに同意し

ところでここでSTと私の最後の問題は、私はjdbi統合レベルでの回避策のコードでそれをここに掲示しなければならないのですか？

jdbiが物事をあまり複雑にすることなく実行できる簡単な回避策がある場合、私たちは確かにそれを検討します。

追加のtemplateEngineはどのようにjdbiにバンドルされますか？ それらはすべて、 coreに不要な外部依存関係をもたらし、1クラスモジュールを作成したり、\を設定したりすることはありません。

IIRC stringtemplateは独自のmvnモジュールを持っているので、それを続けなければならないのではないでしょうか。 とにかく、オプションの依存関係よりも、ユーザーにとって厄介な手間が少ないように思えます。

StringSubstitutorエンジンを提供することに興味があります（まだ提供していない場合）。Mustacheも非常に楽しいようです。

単一の<optional>依存関係を持つ自己完結型の単一クラスである場合、または同様に軽量である場合は、コアに入れることができます。 それ以外の場合は、モジュールを起動してみましょう。 私の好みはガイドラインであり、通過するのが不可能なバーではありませんでした:)

ただし、stringtemplate4モジュールによって設定されたパターンでは壊れます。 そして、私はユーザーとして、Mavenをいじる必要があること、特に依存関係の依存関係よりも嫌いなことはほとんどないことを知っています...

@UseTemplateEngine存在するにもかかわらず、stringtemplateが@UseStringTemplateEngine取得したようです。 これはすべてのテンプレートエンジンにとって望ましい便利なことですか、それとも必要な場合を除いて、今後は一般的な注釈に固執するだけですか？

個人的には、それらをモジュールに分割して、依存関係がクラスパスに推移的に含まれていないと、IDEでクラスを表示することさえできないようにしたいと思います。 NoClassDefFoundErrorは本当に苦痛です。

私は過去にフリーマーカーをたくさん使ってきました。 それのサポートを実装することは楽しい努力かもしれません。 それは直接それを意味するものではありません。 しかし、それは可能です。 パフォーマンスをよく見る必要があります。

他に何もなければ私はそれのスパイクを作ることができます

現在取り組んでいます。 妥当な概念実証ができるまで、プルリクエストを開かない。 テンプレートのロードは静的ではないため、構成の使用には問題があります。動的である必要があります。 したがって、各テンプレートを手動でロードしてキャッシュする必要があります。 stringtemplate4モジュールのクローンを作成し、クラスなどの名前を変更しました。誰かが興味を持っている場合は、jdbiのフォークのmasterブランチで作業しています。

この問題の原因となった状況は、次の組み合わせだと思います。

• StringTemplate 4は通常、シングルスレッドの使用法で非常にうまく機能します（他に何もない場合は予測可能）
• StringTemplate 4は、同時使用に特に重点を置いて設計されていなかったため、既存のユーザーを壊さずに解決するのが難しいバグが発生したため、ほとんどの場合、そのままの状態でした。

StringTemplate 5が作成された場合、安全な並行性（およびおそらく不変性）が基本設計で大きな役割を果たすことを期待します。