Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for build-helper-maven-plugin #48

Closed
hoshposh opened this issue Apr 9, 2018 · 6 comments
Closed

Support for build-helper-maven-plugin #48

hoshposh opened this issue Apr 9, 2018 · 6 comments
Assignees
Milestone

Comments

@hoshposh
Copy link

hoshposh commented Apr 9, 2018

Rather than saving generated artifacts by adding maven-install-plugin declarations, could you detect additional artifacts that are added to the project via the org.codehaus.mojo:build-helper-maven-plugin:attach-artifact plugin goal?

The scenario I am interested in is a multi-platform build storing the generated binaries in the maven repo automatically when mvn clean install is invoked:

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>build-helper-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>attach-artifacts</id>
      <phase>package</phase>
      <goals>
        <goal>attach-artifact</goal>
      </goals>
      <configuration>
        <artifacts>
          <artifact>
            <file>${project.build.directory}/${project.artifactId}-${project.version}-win-amd64.exe</file>
            <type>exe</type>
            <classifier>win-amd64</classifier>
          </artifact>

          <artifact>
            <file>${project.build.directory}/${project.artifactId}-${project.version}-linux-amd64.exe</file>
            <type>bin</type>
            <classifier>linux-amd64</classifier>
          </artifact>
          <artifact>
            <file>${project.build.directory}/${project.artifactId}-${project.version}-mac-amd64.bin</file>
            <type>bin</type>
            <classifier>mac-amd64</classifier>
          </artifact>
        </artifacts>
      </configuration>
    </execution>
  </executions>
</plugin>

It appears that the maven-install-plugin:install-file goal will add secondary files to the local repo, but I am not sure that it will handle the deploy lifecycle.

@raydac
Copy link
Owner

raydac commented Apr 9, 2018

could you explain what do you want to get as result in repository?
at present if you make install in golang project processed by the maven golang wrapper plugin then it just zips sources and resources of project and save the zip file into maven repository, I don't save the result file into repository because it is not cross platform one and target maven repository can be shared between different platforms
potentially I can just add some special flag for install mojo to save and binary result

@raydac raydac self-assigned this Apr 9, 2018
@hoshposh
Copy link
Author

hoshposh commented Apr 9, 2018

In my project I have multiple mvn-golang-wrapper executions to build multi-platform artifacts, so for this project I am more interested in all the cross-platform artifacts getting installed to the local maven repo, but also to be able to deploy the artifacts that are registered with the project to a department artifact repository.

After a brief scan of the code it appears that the plugin could produce a zip artifact with a .mvn-golang extension in the project's bin folder (and leave it there). It could treat this zip as the primary artifact for a maven project with a mvn-golang packaging type. However if you were to register additional artifacts to the project with new classifiers and/or extensions, then mvn install or mvn deploy should handle all of the artifacts (primary and additional).

Thoughts?

@raydac
Copy link
Owner

raydac commented Apr 9, 2018

and why you don't use maven install plugin to install generated files into repository? for instance such codesnipet which installs two built executable files into reository ?

<plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-install-plugin</artifactId>
              <version>2.5.2</version>
              <executions>
                  <execution>
                      <id>install-result-linux</id>
                      <goals>
                          <goal>install-file</goal>
                      </goals>
                      <phase>install</phase>
                      <configuration>
                          <groupId>${project.groupId}</groupId>
                          <artifactId>some-test-all</artifactId>
                          <version>${project.version}</version>
                          <classifier>linux64</classifier>
                          <generatePom>true</generatePom>
                          <packaging>bin</packaging>
                          <file>${basedir}/bin/${base.target.name}-linux-amd64</file>
                      </configuration>
                  </execution>
                  <execution>
                      <id>install-result-win</id>
                      <goals>
                          <goal>install-file</goal>
                      </goals>
                      <phase>install</phase>
                      <configuration>
                          <groupId>${project.groupId}</groupId>
                          <artifactId>some-test-all</artifactId>
                          <version>${project.version}</version>
                          <classifier>windows386</classifier>
                          <generatePom>true</generatePom>
                          <packaging>exe</packaging>
                          <file>${basedir}/bin/${base.target.name}-windows-386.exe</file>
                      </configuration>
                  </execution>
              </executions>
          </plugin>

@hoshposh
Copy link
Author

hoshposh commented Apr 9, 2018

For the mvn install this is fine, but a mvn deploy would end up multiple deployment commands and a pom that is overwritten for each artifact that is deployed, rather than one deployment that contains all the artifacts, with a single pom.

I will try and devote some time to coming up with a pull request, and hopefully it will provide more insight than I am able to convey in these comments.

Cheers!

@raydac
Copy link
Owner

raydac commented Apr 9, 2018

standard deploy also can be used for such purposes imho

 <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-deploy-plugin</artifactId>
              <version>2.8.2</version>
              <executions>
                  <execution>
                      <id>do-deploy</id>
                      <phase>deploy</phase>
                      <goals>
                          <goal>deploy-file</goal>
                      </goals>
                      <configuration>
                          <url> file:///home2/igorm/Temp/m2-repo</url>
                          <groupId>${project.groupId}</groupId>
                          <artifactId>some-deloy-test</artifactId>
                          <file>${basedir}/bin/${base.target.name}-linux-amd64</file>
                          <version>${project.version}</version>
                          <classifier>linux64</classifier>
                          <packaging>bin</packaging>

                          <classifiers>windows386</classifiers>
                          <types>exe</types>
                          <files>${basedir}/bin/${base.target.name}-windows-386.exe</files>
                          
                          <generatePom>true</generatePom>
                      </configuration>
                  </execution>
              </executions>
          </plugin>

@hoshposh
Copy link
Author

hoshposh commented Apr 9, 2018

Yup, correct, you could have a block for the maven-install-plugin and another block for the maven-deploy-plugin, however it would be a smaller file if I could use the build-helper-maven-plugin to describe the supplemental attachments. Then when I invoked mvn install or mvn deploy it would already know of the supplemental files and be able to install or deploy them.

Thanks for the dialog, as I mentioned earlier I will try coming up with a pull request that attempts to show what I am looking for.

@raydac raydac added this to the 2.1.8 milestone Apr 9, 2018
raydac added a commit that referenced this issue Apr 9, 2018
…h boolean configuration flag `installAttached`
hoshposh added a commit to hoshposh/mvn-golang that referenced this issue Apr 10, 2018
- Still rely on the custom mojos to perform the custom golang actions for the project.

- Rely on the apache maven-install-plugin to perform the actions to install project artifacts to the local repo.

- Rely on the apache maven-deploy-plugin to perform the deployment actions to place the project artifacts in a artifact repository.
raydac added a commit that referenced this issue Apr 11, 2018
@raydac raydac closed this as completed Apr 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants