0

I'm using Eclipse m2e in my development environment, and I have a spring-boot maven project(can be viewed as a standard maven jar project with runnable main class in this context) which depends on another maven project in the same workspace(workspace artifact, let's call it moduleB, a sibling of the spring-boot project), when I run the maven goal clean package(the appassembler:assemble goal can be ommited because I configured the execution section of the plugin, see the configuration detail below), the generated assembly in the target directory seems fine, except that the jar of moduleB is missing in the repo. It seems that the plugin is trying to copy every file under the class folder in moduleB according to the log:

...
[INFO] Installing artifact ...
[INFO] Installing artifact /foo/bar/moduleB/target/classes to /foo/bar/repo/groupid/artifactid/0.0.1-SNAPSHOT/moduleB-0.0.1-SNAPSHOT.jar
[INFO] Installing ...
...

How to resolve this? Do I have to install moduleB into the maven local repository before running the assemble? Is there any way to bypass this step because I don't want to mess up the repository with unstable artifacts.

P.S. configuration of the plugin:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>appassembler-maven-plugin</artifactId>
    <version>1.10</version>
    <configuration>
        <configurationDirectory>conf</configurationDirectory>
        <configurationSourceDirectory>src/main/resources</configurationSourceDirectory>
        <copyConfigurationDirectory>true</copyConfigurationDirectory>
        <includeConfigurationDirectoryInClasspath>true</includeConfigurationDirectoryInClasspath>
        <assembleDirectory>${project.build.directory}/someApp</assembleDirectory>
        <extraJvmArguments>-Xms128m</extraJvmArguments>
        <logsDirectory>logs</logsDirectory>
        <repositoryLayout>default</repositoryLayout>
        <repositoryName>repo</repositoryName>
        <showConsoleWindow>true</showConsoleWindow>
        <platforms>
            <platform>windows</platform>
            <platform>unix</platform>
        </platforms>
        <binFileExtensions>
            <unix>.sh</unix>
        </binFileExtensions>
        <programs>
            <program>
                <mainClass>someClass</mainClass>
                <id>app</id>
                <platforms>
                    <platform>windows</platform>
                    <platform>unix</platform>
                </platforms>
            </program>
        </programs>
    </configuration>
    <executions>
        <execution>
            <id>assemble</id>
            <goals>
                <goal>assemble</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Update #1:

I bypass the spring-boot:repackage goal because it encapsulates everything in one jar, including the configuration files which I want to be conveniently editable in production environment. Here's the earlier question I asked: Alternatives to distribute spring-boot application using maven (other than spring-boot:repackage)

Community
  • 1
  • 1
carusyte
  • 1,549
  • 17
  • 21
  • Why aren't you letting the spring-boot plugin create the executable jar? Why are you trying to work around that? – M. Deinum Jan 29 '16 at 09:13
  • I'm somewhat confused. Is B a child or sibling module of A? Or is it an entirely different Maven artifact and you are using Eclipse m2e's workspace resolution to avoid installing it into a local repository? Generally I find workspace resolution to be an antipattern and a sign that the dependent module is tightly coupled to its consumer. – Thorn G Jan 29 '16 at 15:35
  • @M. Deinum Do you mean the `spring-boot:repackage` goal? This goal is very convenient for simple deployment purpose, except that it encapsulates everything in one big jar file, including all the configuration files which I want them to be editable in production environment. Actually I've already asked about this goal in an earlier post: [spring-boot:repackage](http://stackoverflow.com/questions/35061619/alternatives-to-distribute-spring-boot-application-using-maven-other-than-sprin) – carusyte Jan 30 '16 at 03:01
  • @Tom G B is a sibling module of A. And I am using Eclipse m2e. The workspace resolution feature, in my opinion, has both pros and cons. To be more specific, in my situation, I decoupled my entire "big project" into sub modules in order to write less code by reusing some of the common services/infrastructure, but all the sub modules are yet to be reusable by other projects, so I think they are somewhat restricted in the "big project" boundaries only, which is not yet suitable to be installed in the maven repository. – carusyte Jan 30 '16 at 03:14
  • Your configuration doesn't have to be in the files (I suggest a read of the documentation on where the configuration can be stored). – M. Deinum Jan 30 '16 at 18:34

0 Answers0