Make attachment of source zip artifact optional

[mpontes]

Since version 2.3.0, the zip with the source (the .mvn-golang one) is now being installed/deployed as a zip. We are using mvn-golang-wrapper together with maven-assembly-plugin, where the latter generates a zip file containing a compiled golang executable suitable for running as an AWS Lambda. Since 2.3.0, the source zip being generated by mvn-golang-wrapper is installed/deployed as a zip, which overrides the zip being generated by maven-assembly-plugin.

Ideally we would be able to prevent the source zip from being attached as an artifact of the module, as it can be done with attach=false in maven-assembly-plugin, meaning a deploy/install of the module only deploys the zip that we want (the assembly one).

To be clear, we've always had a problem of the resulting source zip being (unwantedly) uploaded to our repository, but with the extension of .mvn-golang. We ended up deploying both the source zip and our zip containing the wanted binary created by the assembly plugin. Since 2.3.0, the artifact of the mvn-golang-wrapper plugin is now conflicting with our zip, making the issue worse.

[raydac]

did you try to skip the install execution? try provide property mvn.golang.install.skip

<properties>
   <mvn.golang.install.skip>true</mvn.golang.install.skip>
</properties>

[mpontes]

Thanks, I tried that approach, with the latest version of the plugin (2.3.10), it looks like it does what I asked for! But for the sake of documenting this, I am now unfortunately hitting another issue (The packaging plugin for this project did not assign a main file to the project but it has attachments. Change packaging to 'pom'.), which seems to a Maven issue, not a mvn-golang-wrapper one. mvn-assembly-plugin is attaching a new file, but it's not the main one. If I disable attaching the golang main file with mvn.golang.install.skip, Maven now complains with the above.

This may not be something that can be fully addressed by mvn-golang-wrapper, unless I'm looking at this wrong.

[raydac]

in the case could help flag to allow incomplete projects from maven deploy plugin

<plugin>
      <artifactId>maven-install-plugin</artifactId>
      <groupId>org.apache.maven.plugins</groupId>
      <configuration>
          <allowIncompleteProjects>true</allowIncompleteProjects>
      </configuration>
</plugin>

[raydac]

also looks like that such user property of maven project can help

<properties>
    <allowIncompleteProjects>true</allowIncompleteProjects>
</properties>

[raydac]

@mpontes did you manage to resolve issue?

[mpontes]

Hi, sorry for the delay, just wanted to try a few more things. allowIncompleteProjects alongside with mvn.golang.install.skip does the trick, but I'm not entirely happy with it because it throws up a huge warning and clearly the Maven developers are against it.

I think there's two ways mvn-golang-wrapper could help here to work in line with how the other "default" Maven plugins work:

The first one is to allow another plugin to overwrite its main artifact – this feels "dirty" but it's an incredibly common strategy condoned by combinations like maven-jar-plugin + maven-shade-plugin or maven-jar-plugin + maven-assembly-plugin to to only generate one final file. For that, I think we'd need:

• Have mvn-golang-wrapper not generate its main file as.mvn-golang and then renaming its extension to .zip, as that seems to make it impossible to use a "replace the main artifact" strategy. Not sure if you could allow for zip packaging and output that onto the build folder, since that's the extension you're generating in the end upon install anyway?
• Honor the standard finalName property under build – this seems to be ignored, so even if the extensions match, there's no way of matching a particular output from another plugin with the output from golang-wrapper.

The second strategy, which IMO would be even more useful here and doesn't seem to have potential for breaking backwards compatibility, would be to allow mvn-golang-wrapper to run under pom packaging when the execution is manually bound. This is supposedly meant to work from what I could gather: all one should have to do is to bind the phase manually under a plugin execution. I've attempted to get mvn-golang-wrapper to run under pom packaging by setting the phase manually like:

<plugin>
  <groupId>com.igormaznitsa</groupId>
  <artifactId>mvn-golang-wrapper</artifactId>
  <version>2.3.10</version>
  <extensions>true</extensions>
  <executions>
    <execution>
      <id>default-build</id>
      <phase>compile</phase>
      <configuration>
        <packages>
          <main>test.go</main>
        </packages>
        <targetOs>linux</targetOs>
      </configuration>
    </execution>
  </executions>
</plugin>

to no avail, mvn-golang-wrapper doesn't run. I can get other plugins to run while in pom packaging, but not this. If this worked, one could:

• Set packaging as pom
• Bind mvn-golang-wrapper to a phase manually to get it to execute
• Set mvn.golang.install.skip to get it to not install its own artifact
• Use maven-assembly-plugin or anything else the user wants to generate the artifact – Maven will happily install/deploy this without complaining because it doesn't care about "main" artifacts for pom packaging

Sorry for the potentially complicated request, let me know what you think.

[raydac]

maven complains when it can't find any attached artifact in the project, may be in the case just try the build helper plugin? just provide some artifact or archive if needed and maven won't be complaining for missing artifact

[mpontes]

Hi, no, that won't work. maven-assembly-plugin already attaches the (zip) artifact just fine, no problem on that end. It's just that when packaging is mvn-golang, and I use mvn.golang.install.skip, I need <allowIncompleteProjects>true</allowIncompleteProjects> and even then Maven complains loudly that the module is broken because there's no "main" artifact. The main artifact needs to be one that matches the packaging I assume.

If the packaging of the module is set to pom, mvn-golang-wrapper doesn't run, even if I attach the phase manually, as I've described above, which seems like the main issue here. Other plugins (jar, surefire, assembly, etc) can all be made to run under a module with pom packaging if the phase is set manually.

[raydac]

also it is possible just split maven project module to two ones - build and install and in the case installing module can be any type and make any business without affect of build module