メインコンテンツまでスキップ

モジュールプロジェクトの構成

本項では、モジュールを作成するためのプロジェクトに関して説明します。

開発環境の構築が完了していることが前提となります。 開発環境の構築については 開発環境の準備 を参照してください。

モジュールプロジェクト​

intra-mart では、モジュールを効率的に製造するためのプロジェクトの仕様を定義しています。

モジュールに関するプロジェクトとして モジュールプロジェクト が存在します。 モジュールプロジェクトは、モジュールを構成するためのプロジェクトであり、以下の性質があります。

  • モジュールプロジェクトには、開発したプログラムコードやリソースが内包されている
  • モジュールプロジェクトでは、プログラムコードや、リソースを区分けするためにパーティショニングが行われる

この、コード・リソースの振り分けの規定となるディレクトリのパーティショニングルールを、 定義済みディレクトリ と呼びます。

開発者は、開発したコード・リソースの種類や用途に応じて決められた定義済みディレクトリに格納することで、モジュールプロジェクトからモジュールへの変換をツールにより自動的に行うことが可能になります。

また、モジュールプロジェクトは、モジュールを構成するためのリソースだけでなく、自身が構築するモジュールに関する識別情報や依存情報などを定義する モジュールメタデータ ファイルを持つ必要があります。

このモジュールメタデータが、モジュールプロジェクトから構築されるモジュールに含まれる形となり、モジュールを操作する際の基準となります。

モジュールを構成したい場合、このモジュールプロジェクトが必要です。 モジュールプロジェクトが持つべきリソースとそれぞれの役割について、以下で解説します。

リソース配置​

モジュールプロジェクトとして定義されている 定義済みディレクトリ に関しての説明です。

ここでは具体的に用途毎のファイルをどのディレクトリに配置するかを説明します。

用途による大別​

まず、プロジェクトにはプログラムコードやリソースといった資材に関する大きな用途に応じて以下の3種類のパーティショニングが行われます。

  • main
    • そのプロジェクトの主たるコード・リソースを配置するディレクトリです。
    • 基本的にモジュールが提供する機能を実現するためのすべてのコード・リソースはこのディレクトリの配下に配置されることを想定しています。
  • test
    • テストを行うためのコード・リソースを配置するためのディレクトリです。
    • main に配置されたコード・リソースが実現する機能が、実際に想定したとおりに動作するかを検証するためのテスト用の資材が全てここに配置されることを想定しています。
    • 主に、ユニットテスト用のコードを配置するために利用します。このディレクトリ配下に配置されたコード・リソースは IM-Juggling を利用して作成される war ファイル内に配置されることはありません。
  • sample
    • このプロジェクトが提供する機能を用いた、サンプルを構築するコード・リソースを配置するディレクトリです。
    • このディレクトリ配下に配置されたコード・リソースは IM-Juggling を利用して war ファイルを作成するウィザード中において、 サンプルを含める 選択をした場合にのみ war ファイル内に配置が行われます。

定義済みディレクトリ​

用途による大別に合わせて、 定義済みディレクトリ と呼ばれるより細かいプログラムコードやリソースに対するパーティショニングを行います。

定義済みディレクトリに関するパーティショニングは、上記 main/test/sample 配下に全て同じ仕様で行われます。

定義済みディレクトリは以下になります。

  • java
    • 用途
      • Java ファイルを格納するためのディレクトリです。
      • パッケージ毎にフォルダを作成し、Java ソースコードを配置して下さい。
    • 対象要素例
      • Java ファイル（*.java）
  • resources
    • 用途
      • Java ファイル以外で、プログラム中に利用するファイル等を格納するディレクトリです。
      • properties ファイル等、Java ソースコード以外に Java クラスパス上から参照する必要があるリソースを配置して下さい。
    • 対象要素例
      • プロパティファイル（*.properties）
      • XML ファイル（*.xml）
      • META-INF フォルダ
  • jssp
    • 用途
      • スクリプト開発のソースを格納するためのディレクトリです。
      • このディレクトリは更に規定のディレクトリが存在します。
        • platform：intra-mart 基盤として提供されるソースコードを配置するディレクトリです。通常このディレクトリにソースを配置する必要はありません。
        • product：intra-mart 基盤上に配置するアプリケーションのソースコードを配置するディレクトリです。
        • compatible：intra-mart ver 7.2 以前の機能との互換機能用のソースコードを配置するディレクトリです。通常このディレクトリにソースを配置する必要はありません。
        • src：製品以外で独自に作成したソースコードを配置するディレクトリです。他の製品等のソースコードとの重複を避けるためにプロジェクト固有のコードを意味するディレクトリをこのディレクトリ直下に作成しそのディレクトリにソースコードを配置する事を強く推奨します。
    • 対象要素例
      • プレゼンテーションページ（*.html）
      • ファンクションコンテナ（*.js）
  • conf
    • 用途
      • 利用者が変更可能な設定ファイルを配置するディレクトリです。
    • 対象要素例
      • プロパティファイル（*.properties）
      • XML ファイル（*.xml）
      • インポートデータ（*.*）
  • public
    • 用途
      • 静的コンテンツを格納するディレクトリです。
      • このディレクトリには、クライアントサイドの Javascript、CSS、イメージファイル等を格納します。
      • パフォーマンスを目的として静的コンテンツを Web サーバに配置する場合にこのディレクトリに格納されているリソースが利用されます。
    • 対象要素例
      • HTML ファイル（*.html）
      • CSS ファイル（*.css）
      • Javascript ファイル - クライアントサイド（*.js）
      • イメージファイル（*.jpg, *.png, *.gif, *.bmp）
  • webapp
    • 用途
      • Web コンテンツの中でも、動的コンテンツを格納するディレクトリです。
      • 主に、jsp ファイルや、war ファイルに含まれる WEB-INF/lib フォルダ内に配置するライブラリ等を格納します。
    • 対象要素例
      • JSP ファイル（*.jsp）
      • META-INF フォルダ
      • WEB-INF フォルダ
  • storage
    • 用途
      • Storage Service に初期配置するファイルを格納するディレクトリです。
      • このディレクトリには更に既定のディレクトリが存在します。
        • system：プログラム中に利用されるディレクトリです。一般の利用者が触れる必要のないファイルを格納して下さい。
        • public：一般の利用者が利用するディレクトリです。
    • 対象要素例
      • 対象ファイル（*.*）
  • schema
    • 用途
      • conf ディレクトリに XML ファイルを配置した場合、それに対応する XML Schema を配置するためのディレクトリです。
      • XML Schema 以外に、特定の設定ファイルに対応したスキーマファイルが存在する場合もこのディレクトリに配置して下さい。
    • 対象要素例
      • XML Schema ファイル（*.xsd）
  • generated
    • 用途
      • 自動生成された Java ファイルを格納するためのディレクトリです。
      • 自動生成であることを明確にディレクトリとして分けることで、それ以上手を加えるものでないことを明確にしています。
    • 対象要素例
      • 自動生成された Java ファイル（*.java）
  • plugin
    • 用途
      • プラグイン（PluginManager）として利用する設定ファイルを格納するディレクトリです。
    • 対象要素例
      • XML ファイル（*.xml）

プロジェクトのリソース配置​

プロジェクトは、用途による大別と、定義済みディレクトリを用いて以下のようにパーティショニングされます。

%PROJECT%
   └ src
      ├ main
      │  ├ java
      │  ├ resources
      │  ├ jssp
      │  ├ conf
      │  ├ public
      │  ├ webapp
      │  ├ storage
      │  ├ schema
      │  ├ generated
      │  └ plugin
      ├ test
      │  ├ java
      │  ├ resources
      │  ├ jssp
      │  ├ conf
      │  ├ public
      │  ├ webapp
      │  ├ storage
      │  ├ schema
      │  ├ generated
      │  └ plugin
      └ sample
         ├ java
         ├ resources
         ├ jssp
         ├ conf
         ├ public
         ├ webapp
         ├ storage
         ├ schema
         ├ generated
         └ plugin

メタデータ​

モジュールが、単なるコード・リソースの集まりでは無い、意味を持った「機能」の1つとするためにメタデータを持ちます。

メタデータとは、モジュールに関する属性情報の集合のことを指します。

本項では、メタデータが具体的にどの様な情報を取り扱っているのかを説明します。

モジュールメタデータ​

モジュールメタデータは、モジュールがどの様なものであるかを定義したものです。

具体的には、以下の3種類の情報から構成されます。

  • モジュールの識別情報
  • モジュールの依存情報
  • モジュールの付加情報

各情報の詳細を以下に示します。

モジュールの識別情報​

モジュールの識別情報とは、モジュールを一意に決定する属性情報群を指します。

それ以外にも、モジュールの名称や機能概要、提供ベンダーなどの詳細情報も識別情報として大別されます。

以下に識別情報として取り扱う項目を示します。

  • モジュールID
    • モジュールを一意に識別するためのユニークな文字列です。
    • com.example.sample-module 等、ドットで区切られた文字列により定義します。半角英数字、ハイフン（-）、アンダースコア（_）、ドット（.） が利用できます。
    • 原則、モジュールIDは他のモジュールIDと同じものは設定できません。
    • jp.co.intra_mart で始まるモジュールIDは利用できません。
    • モジュールIDを "." で分割した末尾のID（foo.bar であれば bar に当たる部分）には、im で始まるIDを指定することは出来ません。
  • バージョン
    • モジュールのバージョニングを表します。
    • "8.0.0" 等、メジャーバージョン、マイナーバージョン、マイクロバージョンを指定します。
  • モジュールタイプ
    • このモジュールの種別を示します。
    • "module" を指定します。
  • モジュール名称
    • モジュールの名称を表します。
  • モジュール詳細
    • モジュールに関する詳細な説明、目的、想定などを表します。
  • モジュールベンダー
    • このモジュールがどのベンダーから提供されたのかを表します。

モジュールの依存情報​

モジュールの依存情報とは、モジュールを構成するにあたって、必要となる他のモジュールについての属性情報群を指します。

以下に依存情報として取り扱う項目を示します。

  • 依存モジュール
    • 依存するモジュールの情報です。
    • この情報には、以下の項目を含みます。
      • 依存モジュールID
        • 依存するモジュールのIDを表します。
      • 依存バージョン
        • 依存するモジュールの、どのバージョンに依存するのかを表します。
        • ここで示されたバージョンは、基本的に動作が確認できているバージョンを設定することを想定しています。
      • 依存許容最大バージョン
        • 依存するモジュールの、最大でどのバージョンまでを許容するかを表します。
        • このバージョンが依存バージョンよりも大きい値で設定されていた場合、依存バージョンから最大依存バージョンまでの範囲のすべてのバージョンに、依存可能であるという解釈になります。
      • 依存許容最小バージョン
        • 依存するモジュールの、最小でどのバージョンまでを許容するかを表します。
        • このバージョンが依存バージョンよりも小さい値で設定されていた場合、最小依存バージョンから依存バージョンまでの範囲のすべてのバージョンに、依存可能であるという解釈になります。

モジュールの付加情報​

モジュールの付加情報とは、モジュールに対して任意の追加情報を付加するための属性情報群を指します。

以下に付加情報として取り扱う項目を示します。

  • タグ
    • モジュールの持つ任意の特性を列挙し、表現します。
    • intra-mart では、タグに各特性を示す情報を付与しています。例えば、このモジュールは intra-mart 製のモジュールか、サードパーティのライブラリをラップしたモジュールか、といった特性を付ける際に利用します。

これらのメタデータは、モジュールメタデータファイル module.xml として定義します。 各項目の XML 上での表現と制約は、モジュールメタデータ(module.xml) を参照してください。

プロジェクトの作成​

モジュールプロジェクトの作成手順は、プロジェクトの作成 を参照してください。

依存関係の管理​

Accel CLI で生成されたプロジェクトの pom.xml は、intra-mart が提供する共通の親 POM（parent）を継承しています。 この parent は、intra-mart Accel Platform を構成する各モジュールのバージョンを一元管理する BOM（Bill of Materials） を取り込んでいます。

これにより、依存するモジュールのバージョンを個別に指定する必要がなくなり、依存バージョンの整合性確保とビルドの再現性が得られます。

リポジトリの参照設定（settings.xml）と親 POM（parent）の仕様の詳細は、リポジトリ設定(settings.xml) と 親 POM(parent) を参照してください。

依存関係の追加​

開発するモジュールが他のモジュールやライブラリに依存する場合、pom.xml の <dependencies> に依存を追加します。

<dependencies>
   <!-- intra-mart モジュール: <version> は記述しない(BOM が解決) -->
   <dependency>
      <groupId>jp.co.intra_mart</groupId>
      <artifactId>im_workflow</artifactId>
   </dependency>

   <!-- intra-mart 以外のライブラリ: <version> を記述する -->
   <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.2</version>
      <scope>test</scope>
   </dependency>
</dependencies>
注意

jp.co.intra_mart:* の依存には <version> を記述しないでください。<version> を記述すると、その値が優先され、BOM が管理するバージョンが上書きされます。

バージョンの更新​

依存する intra-mart モジュール群のバージョンをまとめて更新するには、parent の <version> の suffix を差し替えます。

   <parent>
      <groupId>jp.co.intra_mart</groupId>
      <artifactId>parent</artifactId>
-     <version>8.0.6-2025-autumn</version>
+     <version>8.0.6-2026-spring</version>
   </parent>

親 POM のバージョン修飾子とアップデートリリースの対応については、親 POM(parent) を参照してください。

プロジェクトのビルド​

本項では、作成したプロジェクトのビルド方法を説明します。

ビルドは、VSCode の統合ターミナル等から Bun を利用して行います。実行時のカレントディレクトリはビルド対象となるプロジェクトのルートです。

はじめに、依存関係をインストールします。package.json に記載された依存関係が取得され、node_modules ディレクトリが生成されます。

bun install

続いて、ユーザモジュールをビルドします。package.json の build スクリプト（内部的に Maven を呼び出す）が実行され、ユーザモジュールが生成されます。

bun run build

ビルドが正常に完了すると、target フォルダ配下に zip 形式の成果物が配置されます。

{ARTIFACT_ID}-{VERSION}.zip

例: my-project-0.1.0.zip

このファイルが、モジュールファイルです。 IM-Juggling 上からユーザモジュールとしてインポートすることで、成果物をデプロイ対象に含めることができます。