Ebean Gradleと友達になり、IntelliJ Ideaで平和を作る方法

最後に、Webプロジェクトを開始するために成熟しました。 必要なソースからタスクを集約する別のtodoマネージャー。 それは魂のためのプロジェクトとして計画されたので、とてもきれいで正しい。 アーキテクチャとテクノロジーに妥協はありません。 ベストプラクティスのみ、ハードコアのみ。 そして、もちろん、これはすべて、お気に入りのIntellij IDEAにそれをプッシュするつもりでした。



Javaを7年間（最後の2つはScalaと混合）してから、Groovyを試したかったのです。 組み立てにはもちろん、Gradleが人気があり便利です。 レールはあまりにも「ハック」されているように見えたので、 Spring Bootを使用して、WebにSpringを使用することにしました。 そして、すべてが素晴らしく、ORMがうまくいかなかっただけです。 職場では、お客様が個人的に嫌うHibernateを見て（笑わないでください-別の話です）、それを私たちの自転車に置き換えました。 ネガティブな経験と、2、3のエンティティのモンスターを引っ張りたくないというのは、仕事をしました-休止状態は難しいです！ 私は完全に異なるものを試してみたかった。 偶然、選ばれたEbeanに出会いました。



最終的なスタックの選択後、作業が沸騰し始めました。 しかし、残念ながら、機能を備えたカートはまだまだ機能していません。 キャットの下で、その理由の誠実な言い訳。

エビーン

私の意見では、このオープンソースORMフレームワークは、古典的なJPA実装を嫌う人によって作成されたもので、流行に敏感な人に好かれています。 主な機能：

• 使い慣れたマッピング（java.persistenceアノテーションを使用）;
• シンプルなAPI;
• セットアップが簡単。
• 柔軟なフェッチ関連エンティティ。
• 部分サンプリング;
• 変更の追跡。
• セッションの不足;
• ネイティブトランザクションのサポート
• 非同期ロード。
• オートチューニングも！

つまり、通常の非エンタープライズWebアプリケーションに必要なすべてのものです。 フレームワークの作成者は途方もない仕事をしました。 Playの通常のORMの1つとして追加されたのは、何の理由もなかったと思います！ 最初は、 サイトが何らかの形で不十分に更新され、開発が凍結したことを恐れています 。 ただし、GitHubにはavaje-ebeanorm 4.xの非常に新しいバージョンがあります 。 そして、コミュニティとPlayの人気のおかげで、プロジェクトの開発は継続しています。 githubでのアクティビティの証拠として：







Ebeanでの基本的なクエリの例を次に示します。

// find an order by its id Order order = Ebean.find(Order.class, 12); // find all the orders List<Order> list = Ebean.find(Order.class).findList(); // find all the orders shipped since a week ago List<Order> list = Ebean.find(Order.class) .where() .eq("status", Order.Status.SHIPPED) .gt("shipDate", lastWeek) .findList();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エンティティの作成、保存、更新：

 Order order = new Order(); order.setOrderDate(new Date()); ... // insert the order Ebean.save(order); //If the bean was fetched it will be updated Order order = Ebean.find(Order.class, 12); order.setStatus("SHIPPED"); ... // update the order Ebean.save(order);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

部分オブジェクトを操作する：

 // find order 12 // ... fetching the order id, orderDate and version property // .... nb: the Id and version property are always fetched Order order = Ebean.find(Order.class) .select("orderDate") .where().idEq(12) .findUnique(); // shipDate is not in the partially populated order // ... so it will lazy load all the missing properties Date shipDate = order.getShipDate(); // similarly if we where to set the shipDate // ... that would also trigger a lazy load order.setShipDate(new Date());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例に着想を得て、最新のアクティブにサポートされているバージョン4.1.8を使用するという最終決定が下されました。 闘志。 build.gradleに依存関係を追加します。

 compile('org.avaje.ebeanorm:avaje-ebeanorm:4.1.8')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作成された構成：

 @Configuration @PropertySource("config/db.properties") class EbeanConfig { @Autowired DbConfig dbConfig @Bean EbeanServer ebeanServer() { EbeanServerFactory.create(serverConfig()) } ServerConfig serverConfig() { new ServerConfig( dataSourceConfig: dataSourceConfig(), name: "main", ddlGenerate: false, ddlRun: false, defaultServer: true, register: true, namingConvention: new MatchingNamingConvention() ) } DataSourceConfig dataSourceConfig() { new DataSourceConfig(driver: dbConfig.driver, username: dbConfig.username, password: dbConfig.password, url: dbConfig.url) } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、テストエンティティ：

 @Entity class TestEntity { @Id UUID id Integer value }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私はすでに皆の愛する利益を見越して手をこすりました。 しかし... ...おとぎ話はありません。もちろん、 java.lang.IllegalStateException：BeanクラスxxxTestEntityは拡張されていませんでしたが 、最初はすべてが落ちましたか？



通常、人は何かが失敗した場合にのみドキュメントを読みます。 そしてそれはさらに良いことです。 Ebeanの通常の操作では、アセンブリ段階で.classファイルのバイトコードを展開する必要があることがわかります。 コンパイル直後。 なぜこれが必要なのですか？ ほとんどすべてのORMはクラスに埋め込まれていますが、それらのほとんどは単純に異なる方法でねじられています。 たとえば、Hibernateはcglibを介してランタイムプロキシを作成し、Lazyコレクションへのアクセスをインターセプトします。 透明で正直な怠け者は、このようなハッキングなしでは実行できません。 Ebeanは、全員とともに、遅延読み込みと部分オブジェクトをサポートし、保存操作中にサーバーに不要なデータを送信しないように各フィールドの変更を追跡します。



ライブラリの初期バージョンは、プロキシへの2つのアプローチをサポートしていました。ClassLoaderを介してロードするときに.classファイルにパッチを適用し、クラスコードをインスツルメンテーションします（JVMの開始時にエージェントを接続する必要がありました）。 時間が経つにつれて、サポートを容易にするために、最初のオプションのみが残りました。



うーん...難しいですが、...人々はどういうわけかPlayフレームワークでEbeanと一緒に住んでいますか？ ORM自体には、コンパイルされた.classファイルのバイトコードを展開できるebeanorm-agentライブラリと、Playが正常に使用するSBTがそれを正常に使用できるライブラリが付属しています。 Playでのコードのビルドは内部のみであるため、すべてが時計のように機能します。 そして、誰もおそらく舞台裏で何が起こっているのか推測しません。

グラドル

しかし、質問は、Gradleにそのような機能はありますか？ Maven用のプラグインは間違いなくあります。 しかし、Gradleにとっては、まったく何も見つかりませんでした（たぶん私は見苦しかったです）。 最初は動揺し、このベンチャーを辞めようとさえ考えました...しかし、最後の瞬間に私は集まり、問題を終わらせないことを決めました。

だから、不足しているプラ​​グインを作成してください！

Gradleに独自のビルドツールを追加する最も便利な方法は、プロジェクトルートディレクトリにbuildSrcモジュールを作成することです。 このモジュールのコードは、他のすべてのビルドスクリプトで自動的に使用可能になります（すべてのオプションについては、 ここで説明します ）。



次に、 buildSrcディレクトリ内にbuild.gradleを作成します。

 apply plugin: 'groovy' repositories { mavenCentral() } dependencies { //      compile 'org.avaje.ebeanorm:avaje-ebeanorm-agent:4.1.5' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

buildSrcアプローチではプラグインを作成する必要はありませんが（Groovyスクリプトからコードを記述して呼び出すことができます）、Gradle APIを拡張することで正しい方法を実行します。 結局のところ、確かに、後で、すべてを完成品として整理し、一般的な使用のためにどこかに配置したいと思うでしょう。



プラグインの主なアイデアは、Java、Groovy、またはScalaをコンパイルする各段階の後にEbeanが使用するコンパイラーによって作成されたファイルを見つけて処理することです。 この問題は、おおよそ次のように解決されます。

 class EbeanPlugin implements Plugin<Project> { //   - ! private static def supportedCompilerTasks = ['compileJava', 'compileGroovy', 'compileScala'] //     ,   void apply(Project project) { //        def params = project.extensions.create('ebean', EbeanPluginParams) //  ,    ... def tasks = project.tasks //...         supportedCompilerTasks.each { compileTask -> tryHookCompilerTask(tasks, compileTask, params) } } private static void tryHookCompilerTask(TaskContainer tasks, String taskName, EbeanPluginParams params) { try { def task = tasks.getByName(taskName) //      , ..  task.doLast({ completedTask -> //        enhanceTaskOutput(completedTask.outputs, params) }) } catch (UnknownTaskException _) { ; //    } } private static void enhanceTaskOutput(TaskOutputs taskOutputs, EbeanPluginParams params) { //      ,      taskOutputs.files.each { outputDir -> if (outputDir.isDirectory()) { def classPath = outputDir.toPath() // ,        def fileFilter = new EbeanFileFilter(classPath, params.include, params.exclude) //     new EBeanEnhancer(classPath, fileFilter).enhance() } } } } //   ,      build.gradle class EbeanPluginParams { String[] include = [] String[] exclude = [] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、それはエキスパンダー自体次第です。 アルゴリズムは非常に単純です。最初に、フィルターに適したベースディレクトリ内のすべての.classファイルを再帰的に収集し、次にそれらを「エージェント」に渡します。 処理自体は簡単です。入力ストリームから処理するためのラッパーヘルパーだけでなく、エンティティもあります。 両方を作成してリンクした後は、ファイルを開いてトランスフォーム（...）を呼び出すだけで、同時に発生する可能性のあるエラーをキャッチします。 アセンブリ内のすべては次のようになります。

 class EBeanEnhancer { private final Path classPath private final FileFilter fileFilter EBeanEnhancer(Path classPath) { this(classPath, { file -> true }) } EBeanEnhancer(Path classPath, FileFilter fileFilter) { this.classPath = classPath this.fileFilter = fileFilter } void enhance() { collectClassFiles(classPath.toFile()).each { classFile -> if (fileFilter.accept(classFile)) { enhanceClassFile(classFile); } } } private void enhanceClassFile(File classFile) { def transformer = new Transformer(new FileSystemClassBytesReader(classPath), "debug=" + 1);//0-9 -> none - all def streamTransform = new InputStreamTransform(transformer, getClass().getClassLoader()) def className = ClassUtils.makeClassName(classPath, classFile); try { classFile.withInputStream { classInputStream -> def enhancedClassData = streamTransform.transform(className, classInputStream) if (null != enhancedClassData) { //transformer returns null when nothing was transformed try { classFile.withOutputStream { classOutputStream -> classOutputStream << enhancedClassData } } catch (IOException e) { throw new EbeanEnhancementException("Unable to store an enhanced class data back to file $classFile.name", e); } } } } catch (IOException e) { throw new EbeanEnhancementException("Unable to read a class file $classFile.name for enhancement", e); } catch (IllegalClassFormatException e) { throw new EbeanEnhancementException("Unable to parse a class file $classFile.name while enhance", e); } } private static List<File> collectClassFiles(File dir) { List<File> classFiles = new ArrayList<>(); dir.listFiles().each { file -> if (file.directory) { classFiles.addAll(collectClassFiles(file)); } else { if (file.name.endsWith(".class")) { classFiles.add(file); } } } classFiles } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィルターの作成方法は、表示（または恥ずかしい）しても意味がありません。 任意のjava.io.FileFilterインターフェース実装を使用できます。 実際、この機能はオプションです。



FileSystemClassBytesReaderは別の問題です。 これはプロセスの非常に重要な要素です。 トランスフォーマーで必要な場合、関連する.classファイルを読み取ります。 たとえば、サブクラスが分析されると、ebean-agentはClassBytesReaderを介してスーパークラスに@MappedSuperclassアノテーションの存在を確認するよう要求します。 これがないとjava.lang.IllegalStateException：BeanクラスxxxSubClassEntityは拡張されませんか？ ためらうことなく飛び出します。

 class FileSystemClassBytesReader implements ClassBytesReader { private final Path basePath; FileSystemClassBytesReader(Path basePath) { this.basePath = basePath; } @Override byte[] getClassBytes(String className, ClassLoader classLoader) { def classFilePath = basePath.resolve(className.replace(".", "/") + ".class"); def file = classFilePath.toFile() def buffer = new byte[file.length()] try { file.withInputStream { classFileStream -> classFileStream.read(buffer) } } catch (IOException e) { throw new EbeanEnhancementException("Failed to load class '$className' at base path '$basePath'", e); } buffer } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

美しい識別子「ebean」でプラグインを呼び出すには、ebean.propertiesファイルをbuildSrc / resources / META-INFフォルダーに追加する必要があります。

 implementation-class=com.avaje.ebean.gradle.EbeanPlugin
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけです プラグインの準備ができました。



最後に、メインプロジェクトのbuild.gradleに、素晴らしい行を追加します。

 apply plugin: 'ebean' // property-     ebean { //    include = ["com.vendor.product"] exclude = ["SomeWeirdClass"] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここにグラドルとのEbeanの成功した知人の物語があります。 すべてが正常に機能しています。



GitHub gradle-ebean-enhancerでプラグインをダウンロードできます。 残念ながら、今のところ、すべてが未加工であり、コードをbuildSrcにコピーする必要があります。 近い将来、終了してMaven CentralとGradleリポジトリに送信するようにしてください。

IntelliJ Idea

良いニュースは 、Yevgeny KrasikのIdea 13のプラグインがあり、彼に感謝していることです！ プラグインはビルドプロセスを「リッスン」し、コンパイラを熱心に追跡して、.classファイルを展開します。 Idea自体でSpring Bootアプリケーションを実行およびデバッグするには、これが必要です。これは、はるかに便利で使いやすいからです。



悪いニュース：プラグインは、古いバージョンのエージェントライブラリ3.2.2で動作します。 彼女の活動の成果物はEbean 4.xとは互換性がなく、最初は奇妙な行動を起こします。



解決策： githubでフォークを作成し、目的のバージョンのプラグインを再構築します。



すべてが時計仕掛けのようになりました。 アプリケーションが開始されました。 テストエンティティは永続化してロードできました。



実際、それについて書くことはできませんでした...しかし、1つの「しかし」があります。 エンティティの階層の構築を開始し、BaseEntityが@MappedSuperclassを思いついたら、 java.lang.IllegalStateException：BeanクラスxxxSubClassEntityは拡張されませんか？ ここで再び。



javapは、何らかの理由ですべてのサブクラスが拡張されていないことを示しました。 どうして？ なんで？



迷惑なエラーがIDEプラグインに忍び込んだことが判明しました。 現在のクラスを展開するプロセス中に、トランスフォーマーは、いつものように、サブクラスも分析しようとします。 これを行うには、ClassBytesReaderの実装を提供する必要があることを思い出します。 ただし、バイナリデータではなく、何らかの理由でIDEプラグインを実装すると、Groovyのソースコードがトランスフォーマーに「送られ」、それが詰まってしまいます。



そのため、フォークは非常に役立ちました。 それは：

 //virtualFile       Groovy if (virtualFile == null) { return null; } try { return virtualFile.contentsToByteArray(); // o_O ? } catch (IOException e) { throw new RuntimeException(e); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のようになりました：

 if (virtualFile == null) { compileContext.addMessage(CompilerMessageCategory.ERROR, "Unable to detect source file '" + className + "'. Not found in output directory", null, -1, -1); return null; } final Module fileModule = compileContext.getModuleByFile(virtualFile); final VirtualFile outputDirectory = compileContext.getModuleOutputDirectory(fileModule); //      final VirtualFile compiledRequestedFile = outputDirectory.findFileByRelativePath(classNamePath + ".class"); if (null == compiledRequestedFile) { compileContext.addMessage(CompilerMessageCategory.ERROR, "Class file for '" + className + "' is not found in output directory", null, -1, -1); return null; } try { return compiledRequestedFile.contentsToByteArray(); } catch (IOException e) { throw new RuntimeException(e); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

利益！ プラグインの作成者がORMフレームワーク自体の多くを使用しなかったことを認めます。 しかし、私が不満を言うことができる唯一のことは、健全なエラーメッセージの欠如です。 結局のところ、静かに機能しない製品を観察することは何となく悲しいことです。



完全で修正されたプラグインコードは、執筆時点でGitHubの唯一のidea-ebean-enhancerフォークにあります。 インストールの準備ができているzipへのリンクもあります。

まとめ

IntelliJ Ideaユーザーはついに、最新バージョンのEbeanをサポートする完全に機能するプラグインを手に入れました。



Mavenとともに、GradleはこのORMフレームワークをサポートする拡張機能も取得しました。



私の道が読者がこのEbeanがどんな獣であるかを試す勇気を助けることを願っています。 結局のところ、このパスに沿ったすべての重要な障害が克服されたようです。 さて、または少なくともそれはあなたに同様の道を進み、いくつかのなじみのないライブラリの内部を掘り下げることを刺激するでしょう。



また、コードの記述にかかる時間は、この出版物を準備するよりも大幅に短いことも、私にとってはかなり面白そうに思えました。