Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

5.3. Modifying an Existing Maven Project

Overview
링크 복사

If you already have a Maven project and you want to customize it to generate a FAB, perform the following steps:
  1. the section called “Ensure that the package type is JAR”.
  2. the section called “Customize the JDK compiler version”.
  3. the section called “Configure class sharing”.
  4. the section called “Mark test artifacts with the test scope”.
  5. the section called “Specify the requisite dependencies for WS applications”.
  6. the section called “Prefer Blueprint over Spring”.
  7. the section called “Optionally configure JAR manifest headers”.

Ensure that the package type is JAR
링크 복사

A FAB is packaged as a regular JAR file, which is the default package type in Maven. Ensure that the packaging element in your project's pom.xml file contains the value, jar, as shown in the following example: 
<project ... >
  ...
  <packaging>jar</packaging>
  ...
</project>
Copy to Clipboard Toggle word wrap

Customize the JDK compiler version
링크 복사

It is almost always necessary to specify the JDK version in your POM file. If your code uses any modern features of the Java language—such as generics, static imports, and so on—and you have not customized the JDK version in the POM, Maven will fail to compile your source code. It is not sufficient to set the JAVA_HOME and the PATH environment variables to the correct values for your JDK, you must also modify the POM file.
To configure your POM file, so that it accepts the Java language features introduced in JDK 1.6, add the following maven-compiler-plugin plug-in settings to your POM (if they are not already present): 
<project ... >
  ...
  <build>
    <defaultGoal>install</defaultGoal>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
    </plugins>
  </build>
  ...
</project>
Copy to Clipboard Toggle word wrap

Configure class sharing
링크 복사

Any dependencies on standard artifacts already provided by the container should be declared as provided, to prevent the FAB runtime from unnecessarily installing those dependencies again. This typically includes artifacts whose names match the patterns, camel-*, cxf-*, activemq-*, and fabric-*.
For example, if you have an existing dependency on the camel-http artifact, you should modify the dependency by adding the scope element as follows: 
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-http</artifactId>
    <version>2.10.0.redhat-60024</version>
 <scope>provided</scope>
</dependency>
Copy to Clipboard Toggle word wrap
Note
All dependencies with Maven group ID org.apache.camel, org.apache.cxf, or org.apache.activemq are shared by default (equivalent to provided scope), so that the value of the scope element is ignored by default. This behavior changes, however, if the FAB-Provided-Dependency manifest header is specified explicitly—see the section called “Sharing dependencies” for details.
If you have a large number of dependencies to manage, it might be easier to share the standard container artifacts by adding a FAB manifest header. For details, see Example 5.1, “Configuring FAB Manifest Headers in the POM”.

Mark test artifacts with the test scope
링크 복사

Any artifacts needed only for testing must be marked with the test scope, as in the following example: 
<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>${log4j-version}</version>
 <scope>test</scope>
</dependency>
Copy to Clipboard Toggle word wrap
Of course, this is the standard convention in POM files. But it is particularly important to observe this convention with FAB projects. For any test artifacts that are not marked as such, the FAB runtime will attempt to download and install the test artifact into the container at run time.
Important
Because the test-only artifacts are not intended to be installed in the container, it is quite likely that a FAB will fail to deploy properly if test artifacts are not marked with the test scope.

Specify the requisite dependencies for WS applications
링크 복사

Make sure that you declare all of the requisite dependencies for an Apache CXF application and declare these dependencies with provided scope. For example, a basic Apache CXF application that uses the JAX-WS frontend needs the following Maven dependencies: 
<project>
    ...
    <dependencies>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-frontend-jaxws</artifactId>
            <version>2.6.0.redhat-60024</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http</artifactId>
            <version>2.6.0.redhat-60024</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.cxf</groupId>
            <artifactId>cxf-rt-transports-http-jetty</artifactId>
            <version>2.6.0.redhat-60024</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-web</artifactId>
            <version>3.0.6.RELEASE</version>
            <scope>provided</scope>
        </dependency> 
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>
Copy to Clipboard Toggle word wrap

Prefer Blueprint over Spring
링크 복사

If your project uses dependency injection or XML configuration, you should prefer the Blueprint framework over the Spring framework.
Because Blueprint is more tightly integrated with OSGi, it is usually able to find whatever dependencies it needs dynamically at deploy time. By contrast, dependencies introduced by a Spring XML file are more likely to lead to ClassNotFound exceptions at deploy time (FAB is not capable of parsing a Spring XML file to discover the dependencies it introduces).

Optionally configure JAR manifest headers
링크 복사

Although the FAB runtime obtains most of its deployment metadata by scanning the pom.xml file embedded in the JAR, you can also specify FAB-specific configuration settings by adding headers to the JAR's manifest. For example: 
FAB-Version-Range-Digits: 2
FAB-Provided-Dependency: org.acme.foo:* org.apache.camel:* org.apache.cxf:* org.apache.activemq:*
Copy to Clipboard Toggle word wrap
For detailed explanations of all the FAB manifest headers, see Section 5.4, “Configuring a FAB”.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat