Releases of multi-module projects fail without additional undocumented release plugin configuration.

[michaeljfazio]

I have multi-module project with various inter-dependencies between nar modules. Under normal circumstances, the maven "install" goal is set as the default goal for each nar project. This ensures that dependency headers are available during native code compilation to dependent modules. If a "mvn compile" were to run, the multi-module build would fail.

When performing a release, the above still holds true. However, the "work around" is a little different, requiring undocumented configuration (as far as I can tell). In order for a release to work, the release plugin must have additional configuration applied so as to execute the "clean install" goals during release preparation:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-release-plugin</artifactId>
  <version>2.4.1</version>
  <configuration>
    <preparationGoals>clean install</preparationGoals>
  </configuration>
</plugin>

Although this might not be considered a bug, as I see it there are at least two options that might be taken to help others better deal with the release scenario:

1. If possible, use plugin extensions to automatically ensure clean install is run during a release preparation.
2. At the very least, add appropriate documentation to the plugin site.

[dscho]

I guess the bug fix would be to find out why an installed nar package's includes can be found as opposed to non-installed ones. Maybe you can make an integration test to demonstrate your scenario? Feel free to use https://github.com/maven-nar/nar-maven-plugin/tree/master/src/it/it0024-namedout as an example of a multi-module integration test.

[GregDomjan]

It would be nice to address the issue of a compile only build, rather than requiring an install build.

Maven only adds the main artifact to the reactor, the NAR package step adds the other AOL classified artifacts. Packaging is too late to be useful for compile.
During compile/test for a JAR the artifact refers to the target/classes location, after packaging it refers to the packaged JAR.

Attaching the packed NAR is done from the NarLayout.attachNars / AbstractNarLayout.attachNar

One of the first points of failure is
When trying to read the narInfo for the compiled dependency it attempts to go direct to the file in the repository rather than using the file attached the the dependency artifact.

There might be issues with artifact layout Vs attaching items early enough and some other general process issues.

This made for a good read http://developer-blog.cloudbees.com/2012/12/maven-and-hack.html in particular this pointer for maven2 - "with code like this to make things work the right way."

[michaeljfazio]

@dscho I will try to put together an integration test once my backlog of tasks is cleared. Hopefully in the coming week.

[dscho]

@S73417H good! We might release 3.0.0 final by then, but there is always 3.0.1, 3.0.2, etc ;-)

[dscho]

@S73417H unfortunately, I have to release a new version right now without your pull request. Please take that as encouragement to get your work into 3.1.1!

[dscho]

@S73417H It's been a full year... has this ticket fallen between the cracks? If so, please close. Otherwise, I would be delighted to accept your contribution!