2

Java (Spring) バックエンドと Javascript (ExtJS/OpenLayers) フロントエンドで構成される Maven で構築された Web アプリケーションがあります。この Web アプリは、多くの派生または子 Web アプリケーションのベースとなっています。つまり、いくつかのドメイン固有の問題に対して機能が拡張された単一の webapp があり、その結果、すべて共通の機能に依存する webapps のセットができました。

これまでは、SVN レポジトリに派生 webapps ブランチのコア コードを用意して、問題を「管理」してきました。これにより、ブランチ間の変更を時折マージできるようになりました。この方法にはさまざまな問題がありますが、それが選択された理由には歴史的な理由がありました。

より良い解決策は、共通のコア コードをライブラリに変換し (難しいことではありません)、派生した子をライブラリにリンクさせることです。残念ながら、一般的な機能の大部分は JavaScript (ExtJS ウィジェットなど) に存在するため、単純に JAR ライブラリを生成するだけでは十分ではありません。「コア javascript」ファイルを子 Web アプリケーションに入れる方法が必要ですが、それらを本当に Java クラスのように扱うことはできませんが、コードベースは Ext JS クラス システムを活用することで最善を尽くしています。

私の質問は、この問題を管理するのに役立つ解決策があるかどうかです。Mavenで似たようなことをした人はいますか? これは非常にまれなケースで、独自の Maven プラグインを作成する必要があるのでしょうか、それとも新しいビルド ツールを探す必要があるのでしょうか?

4

3 に答える 3

1

Maven javascriptプラグインがありますが、ビルドにはMavenよりもはるかに使いやすいものを使用することをお勧めします。

あなたが見ることができる1つのオプションは、その素晴らしいjsプラグインでgradleを使用することです：

// Pull the plugin from a Maven Repo
buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.eriwen:gradle-js-plugin:0.4'
    }
}
// Invoke the plugin
apply plugin: 'js'

ドキュメントから例を入手できます。これはGroovyであるため、「バージョン」を単純なプロパティとして追加できます。たとえば、「file- $ {file-version} .js」では、「file-version」を別の「versions」ファイルで定義できます。インポート：

apply from: 'housekeeping/versions.gradle'

これは、 「Gradleを使用してJSを結合、縮小、および.warファイルにコピーする」方法の例です。

繰り返しますが、Groovyはそれがどのように聞こえるかです=>それはGroovyです。私の意見では、Javaビルドに最適な言語です。

必要な場合に備えて、gradleCSSプラグインもあります。

別の注意点として、このようなオプションがある場合はgitに移行します。これは、関連する多くのプロジェクトの管理が、SVN、さまざまなリポジトリ、またはgitサブモジュールよりもgitの方がはるかに簡単だからです。

于 2012-04-18T02:47:33.437 に答える
1

maven-war-pluginのオーバーレイ機能が役立つ場合があります。

共通の js ファイル (意味がある場合はクラスも) は、別の war ファイルに移動される場合があります。単独でデプロイされない場合は、war プラグインを構成して、欠落しているweb.xmlファイルで<failOnMissingWebXml>要素が失敗しないようにすることができます。次に、各派生 war にオーバーレイ構成を追加します。

于 2012-04-18T02:41:56.100 に答える
0

そのため、いくつかの異なるツールとアイデアを評価した結果、私たちのプロジェクトに最適なのは Maven と SVN 外部の組み合わせであることがわかりました。フロントエンドとバックエンドの依存関係を個別に扱います。

Backend - Core : コアを典型的な JAR パッケージとしてビルドします (ここでは特に何もしません)

フロントエンド - コア: コア フロントエンドをコア バックエンドと同じリポジトリに含めます。これは、コア JAR ビルドによってパッケージ化されていない webapp ディレクトリにあります。代わりに、maven アセンブリ プラグインを使用して個別に ZIP ファイルにパッケージ化されます。

pom.xml

<plugin>
    <artifactId>maven-assembly-plugin</artifactId>
    <version>2.3</version>
    <configuration>
        <descriptors>
            <descriptor>src/assembly/webapp.xml</descriptor>
        </descriptors>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

webapp.xml

<assembly>
    <id>webapp</id>
    <formats>
        <format>zip</format>
    </formats>
    <includeBaseDirectory>false</includeBaseDirectory>
    <fileSets>
        <fileSet>
            <directory>${project.basedir}/src/main/webapp/core/</directory>
            <outputDirectory/>
            <includes>
                <include>**</include>
            </includes>
        </fileSet>
    </fileSets>
</assembly>

バックエンド - 子: コアへの典型的な Maven 依存関係

Frontend - Child : 外部の SVN を使用してコア フロントエンドを参照するか、Web アプリケーションのどこかにドロップされたビルド済みパッケージを使用して参照します。外部を使用すると、Eclipse はコア + 子フロントエンドを透過的に開発できます。ビルド済みパッケージを使用すると、管理がはるかに「簡単」になりますが、変更を移行するのが難しくなります。

全体として、システムは比較的管理しやすく、直感的ではない部分だけが svn の外部を複雑にするリリースに付属しています。しかし、「適切な」リリース ブランチとタグ付けがあれば、対処できないことは何もありません。

また、検討したすべてのオプションを比較対照するブログ投稿も書きました。

于 2012-06-15T04:27:07.353 に答える