e-gineering/gitflow-helper-maven-plugin

Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy

pmbsa opened this issue · 9 comments

pmbsa commented

Hi, I have an issue running builds against my development branch. My deployment to the repo seems to be failing

16:01:46 [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project SpidaParent: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter ->

As I understand things, the distributionManagement element is not required if I use the plugin, I did try to add it anyway but I have the same problem even so.

my pom is as follows

<build>
        <plugins>
            <plugin>
                    <groupId>com.e-gineering</groupId>
                    <artifactId>gitflow-helper-maven-plugin</artifactId>
                    <version>1.4.0</version>
                    <configuration>
                        <releaseDeploymentRepository>snapshots::default::${release.url}::false</releaseDeploymentRepository>
                        <stageDeploymentRepository>stage::default::${stage.url}::true</stageDeploymentRepository>
                        <snapshotDeploymentRepository>release::default::${snapshots.url}::true</snapshotDeploymentRepository>
                </configuration>
                <extensions>true</extensions>
                <executions>
                        <execution>
                            <goals>
                                    <goal>enforce-versions</goal>
                                    <goal>retarget-deploy</goal>
                                    <goal>tag-master</goal>
                                    <goal>promote-master</goal>
                            </goals>
                        </execution>
                </executions>
            </plugin>
        </plugins>
</build>

thanks
Paul

pmbsa commented

Its a bit strange really. All the other deploy processes work brilliantly. I can deploy to stagign for release branch's and I can deploy to the release repo for the master branch just fine. but the deploy to snapshots fails.... I have cloned the plugin repo and put in some debug logging and I can see the setSnapshotArtifactRepository being set correctly but its like the deploy plugin just doesnt see it.

pmbsa commented

With a bit of trial an error I have found a solution that works. Unless I am misunderstanding, I think the maven api is a little squiffy here.

In the RetargetDeployMojo I have had to do the following
case DEVELOPMENT: {
getLog().info("Setting snapshot artifact repository to: [" + snapshotDeploymentRepository + "]");
project.setReleaseArtifactRepository(getDeploymentRepository(snapshotDeploymentRepository));
//project.setSnapshotArtifactRepository(getDeploymentRepository(snapshotDeploymentRepository));
break;

It makes no real sense to me just by looking at the method names that that should work but it does seem to. Not sure whether there is just a bug in the deploy plugin perhaps?.

thanks
Paul

faulomi commented

Hey,

There is a big chance that you did the same mistake than me. I was playing with the plugin, and forgot to use a snapshot version on my development branch.

As enforce-version goal is skipped on development branch, the inconsistency was not detected.
But at the deployment phase, the maven deploy plugin checks the version to define the right target repository. In that case, if you use a non-SNAPSHOT version, it will try to use the releases repository that has been previously set to null by the gitflow-helper-plugin (retarget-deploy goal).

Hope that helps,
Regards,

  • ❤️1
pmbsa commented

hmm, I am pretty sure the version was SNAPSHOT... used on the case match above ase DEVELOPMENT: { it seems to have resolved the correct branch match is just seems to need to use the project.setReleaseArtifactRepository method for some reason even though its SNAPSHOT

bvarner commented

Sorry for the slow response on this stuff -- I'm currently in tight sprint on another project (incidentally it uses this plugin) and don't have the cycles to devote to helping debug this right now.

Do you happen to have your repositories restricted to specific nexus roles?

Or are they open and published and added to the public group?

In setups I've worked with, I think they've always been added to the public group...

pmbsa commented

No problem!... The The repos are all open to all users provided they have a login (no anon access). All the uploads work perfectly actually, its the process of moving from staging to release that seems to cause an issue unless I allow anon access

bvarner commented

I'll make the same suggestion here as I did on #37, try setting the uniqueVersion to 'false' for stage. It should have the same semantics as release, with the exception of the nexus server repository being set to allow redeployment.

bvarner commented

I haven't been able to reproduce this... is there any chance you could give it another go, @pmbsa ?

ArramadaSreedhar commented

I faced the similar issue, after adding the below code in pom.xml then it's resolved.
<distributionManagement> <repository> <id>internal.repo</id> <name>Internal repo</name> <url>file:///home/thara/testesb/in</url> </repository> </distributionManagement>

  • 👍3