Skip to main content

Module Project Structure

This section explains the project used to create a module.

It assumes that the development environment has already been set up. For setting up the development environment, see Preparing the Development Environment.

Module Project​

intra-mart defines a project specification for producing modules efficiently.

The module project exists as the project related to modules. A module project is a project for composing a module, and it has the following characteristics.

  • A module project contains the program code and resources you have developed
  • In a module project, partitioning is performed in order to separate program code and resources

This directory partitioning rule, which governs how code and resources are sorted, is called the predefined directory.

By storing developed code and resources in the predefined directory determined by their type and purpose, developers make it possible for tools to automatically convert a module project into a module.

In addition, a module project must have, beyond the resources for composing the module, a module metadata file that defines identification information and dependency information about the module it builds.

This module metadata becomes included in the module built from the module project and serves as the basis for operating on the module.

If you want to compose a module, you need this module project. The resources a module project should have and the role of each are explained below.

Resource Layout​

This is an explanation of the predefined directories defined for the module project.

Here, we explain specifically which directory to place files in according to their purpose.

Classification by Purpose​

First, the project is partitioned into the following three kinds according to the broad purpose of assets such as program code and resources.

  • main
    • The directory where the project's primary code and resources are placed.
    • In principle, all code and resources for realizing the functionality that the module provides are expected to be placed under this directory.
  • test
    • The directory for placing code and resources used to perform testing.
    • All test assets used to verify that the functionality realized by the code and resources placed in main actually behaves as intended are expected to be placed here.
    • It is used mainly to place code for unit tests. Code and resources placed under this directory are never placed inside the war file created using IM-Juggling.
  • sample
    • The directory where code and resources that build samples using the functionality provided by this project are placed.
    • Code and resources placed under this directory are placed inside the war file only when you choose Include samples during the wizard that creates the war file using IM-Juggling.

Predefined Directories​

Together with the classification by purpose, a finer partitioning of program code and resources called predefined directories is performed.

The partitioning by predefined directories is performed under each of the above main/test/sample directories with exactly the same specification.

The predefined directories are as follows.

  • java
    • Purpose
      • A directory for storing Java files.
      • Create a folder for each package and place the Java source code in it.
    • Example target elements
      • Java files (*.java)
  • resources
    • Purpose
      • A directory for storing files used within the program other than Java files.
      • Place resources that need to be referenced from the Java classpath other than Java source code, such as properties files.
    • Example target elements
      • Property files (*.properties)
      • XML files (*.xml)
      • META-INF folder
  • jssp
    • Purpose
      • A directory for storing script development sources.
      • This directory further contains predefined subdirectories.
        • platform: A directory for placing source code provided as the intra-mart foundation. Normally, you do not need to place sources in this directory.
        • product: A directory for placing the source code of applications deployed on the intra-mart foundation.
        • compatible: A directory for placing source code for compatibility features with functionality from intra-mart ver 7.2 and earlier. Normally, you do not need to place sources in this directory.
        • src: A directory for placing source code you have created independently, outside of products. To avoid collisions with the source code of other products, we strongly recommend creating a directory that represents your project-specific code directly under this directory and placing your source code in that directory.
    • Example target elements
      • Presentation pages (*.html)
      • Function containers (*.js)
  • conf
    • Purpose
      • A directory for placing configuration files that users can modify.
    • Example target elements
      • Property files (*.properties)
      • XML files (*.xml)
      • Import data (*.*)
  • public
    • Purpose
      • A directory for storing static content.
      • In this directory, you store client-side Javascript, CSS, image files, and so on.
      • When placing static content on a web server for performance purposes, the resources stored in this directory are used.
    • Example target elements
      • HTML files (*.html)
      • CSS files (*.css)
      • Javascript files - client-side (*.js)
      • Image files (*.jpg, *.png, *.gif, *.bmp)
  • webapp
    • Purpose
      • A directory for storing dynamic content among web content.
      • It mainly stores things such as jsp files and libraries to be placed in the WEB-INF/lib folder included in the war file.
    • Example target elements
      • JSP files (*.jsp)
      • META-INF folder
      • WEB-INF folder
  • storage
    • Purpose
      • A directory for storing files to be initially placed in the Storage Service.
      • This directory further contains predefined subdirectories.
        • system: A directory used within the program. Store files that general users do not need to touch.
        • public: A directory used by general users.
    • Example target elements
      • Target files (*.*)
  • schema
    • Purpose
      • A directory for placing the XML Schema corresponding to an XML file when you have placed that XML file in the conf directory.
      • If, besides XML Schema, there is a schema file corresponding to a specific configuration file, place it in this directory as well.
    • Example target elements
      • XML Schema files (*.xsd)
  • generated
    • Purpose
      • A directory for storing automatically generated Java files.
      • By clearly separating them into a dedicated directory to indicate that they are automatically generated, it is made clear that they are not to be modified further.
    • Example target elements
      • Automatically generated Java files (*.java)
  • plugin
    • Purpose
      • A directory for storing configuration files used as plugins (PluginManager).
    • Example target elements
      • XML files (*.xml)

Project Resource Layout​

A project is partitioned as follows, using the classification by purpose and the predefined directories.

%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

Metadata​

A module holds metadata so that it becomes not merely a collection of code and resources, but one meaningful "feature."

Metadata refers to a set of attribute information about a module.

This section explains specifically what information the metadata handles.

Module Metadata​

Module metadata defines what a module is.

Specifically, it consists of the following three kinds of information.

  • Module identification information
  • Module dependency information
  • Module supplementary information

The details of each type of information are shown below.

Module Identification Information​

Module identification information refers to the group of attribute information that uniquely determines a module.

In addition, detailed information such as the module's name, functional overview, and providing vendor is also broadly classified as identification information.

The items handled as identification information are shown below.

  • Module ID
    • A unique string for uniquely identifying a module.
    • It is defined by a dot-separated string such as com.example.sample-module. Half-width alphanumeric characters, hyphens (-), underscores (_), and dots (.) can be used.
    • In principle, a module ID cannot be set to the same value as another module ID.
    • Module IDs starting with jp.co.intra_mart cannot be used.
    • For the trailing ID obtained by splitting the module ID on "." (the part corresponding to bar in foo.bar), you cannot specify an ID that starts with im.
  • Version
    • Represents the versioning of the module.
    • You specify the major version, minor version, and micro version, such as "8.0.0".
  • Module Type
    • Indicates the type of this module.
    • Specify "module".
  • Module Name
    • Represents the name of the module.
  • Module Details
    • Represents a detailed description, purpose, assumptions, and so on about the module.
  • Module Vendor
    • Represents which vendor provided this module.

Module Dependency Information​

Module dependency information refers to the group of attribute information about other modules required to compose the module.

The items handled as dependency information are shown below.

  • Dependent Module
    • Information about the module being depended on.
    • This information includes the following items.
      • Dependent Module ID
        • Represents the ID of the module being depended on.
      • Dependency Version
        • Represents which version of the module being depended on is depended on.
        • The version indicated here is expected to be set, in principle, to a version whose behavior has been confirmed.
      • Maximum Allowed Dependency Version
        • Represents up to which version of the module being depended on is allowed at maximum.
        • If this version is set to a value greater than the dependency version, the interpretation is that all versions in the range from the dependency version to the maximum dependency version can be depended on.
      • Minimum Allowed Dependency Version
        • Represents down to which version of the module being depended on is allowed at minimum.
        • If this version is set to a value smaller than the dependency version, the interpretation is that all versions in the range from the minimum dependency version to the dependency version can be depended on.

Module Supplementary Information​

Module supplementary information refers to the group of attribute information for attaching arbitrary additional information to a module.

The items handled as supplementary information are shown below.

  • Tag
    • Enumerates and expresses arbitrary characteristics that the module has.
    • intra-mart assigns information indicating each characteristic to tags. For example, they are used to mark characteristics such as whether this module is made by intra-mart or is a module that wraps a third-party library.

These metadata are defined as the module metadata file module.xml. For the XML representation and constraints of each item, see Module Metadata (module.xml).

Creating a Project​

For the procedure to create a module project, see Creating a Project.

Managing Dependencies​

The pom.xml of a project generated with the Accel CLI inherits the common parent POM (parent) provided by intra-mart. This parent imports a BOM (Bill of Materials) that centrally manages the versions of each module composing intra-mart Accel Platform.

This eliminates the need to specify the versions of dependent modules individually, providing consistency of dependency versions and reproducibility of builds.

For details on the repository reference configuration (settings.xml) and the specification of the parent POM (parent), see Repository Settings (settings.xml) and Parent POM (parent).

Adding Dependencies​

When the module you are developing depends on other modules or libraries, add the dependency to <dependencies> in pom.xml.

<dependencies>
   <!-- intra-mart module: do not write <version> (resolved by the BOM) -->
   <dependency>
      <groupId>jp.co.intra_mart</groupId>
      <artifactId>im_workflow</artifactId>
   </dependency>

   <!-- Non-intra-mart library: write <version> -->
   <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.13.2</version>
      <scope>test</scope>
   </dependency>
</dependencies>
Caution

Do not write <version> for jp.co.intra_mart:* dependencies. If you write <version>, that value takes precedence and overrides the version managed by the BOM.

Updating Versions​

To update the versions of the dependent intra-mart modules all at once, replace the suffix of the parent's <version>.

   <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>

For the correspondence between the parent POM's version qualifier and update releases, see Parent POM (parent).

Building the Project​

This section explains how to build the project you have created.

The build is performed using Bun from the VSCode integrated terminal or similar. The current directory at execution time is the root of the project to be built.

First, install the dependencies. The dependencies listed in package.json are fetched, and the node_modules directory is generated.

bun install

Next, build the user module. The build script in package.json (which internally invokes Maven) is executed, and the user module is generated.

bun run build

When the build completes successfully, a zip-format artifact is placed under the target folder.

{ARTIFACT_ID}-{VERSION}.zip

Example: my-project-0.1.0.zip

This file is the module file. By importing it as a user module from within IM-Juggling, you can include the artifact in the deployment target.