Promote to master doesn't work in multi-module project where some modules are marked as not to be deployed to the repo

[petermcj]

In multi-module projects (ear with ejb/jar/war inside) we only want to upload the ear as it includes all the other modules. We use skip=true with maven-deploy-plugin in the modules that shouldn't be deployed to the repo :

<plugins>
   <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-deploy-plugin</artifactId>
      <configuration>
         <skip>true</skip>
      </configuration>
   </plugin>
</plugins>

Everything works fine until we finish the release branch and the master build that should promote from stage fails as it can't find the artifacts that we have marked to be skipped.

[ERROR] Failed to execute goal com.e-gineering:gitflow-helper-maven-plugin:2.1.0:promote-master (default) on project someskippedmodule: Could not locate artifact catalog in remote repository. Could not find artifact somegroupid-someskippedmodule::txt:catalog:someversion in repo.stages.

[bvarner]

@petermcj - Ahhh, now this is making sense. You're only uploading the .ear.

As a short-term workaround, I'd just suggest you stop skipping the artifact upload.

As a long-term solution, we'd want / desire a test-case, then we'd have to update things to not try to resolve catalogs for skipped deployments. It sounds doable. It's just kinda wonky.

[PayBas]

I've ran into the exact same problem. A quick and dirty workaround:

At: https://github.com/egineering-llc/gitflow-helper-maven-plugin/blob/e979095a44bb71fc43e2951b8fcab692a0c3c554/src/main/java/com/e_gineering/maven/gitflowhelper/AbstractGitflowBasedRepositoryMojo.java#L176 Insert:

        // Check to see if the project can expect any catalogs (and artifacts), or whether deployment is "skipped".
        for (Plugin plugin : project.getBuildPlugins()) {
            if (plugin.getKey().equals("org.apache.maven.plugins:maven-deploy-plugin") && plugin.getConfiguration() != null) {
                Xpp3Dom xpp3Dom = (Xpp3Dom) plugin.getConfiguration();
                Xpp3Dom skipNode = xpp3Dom.getChild("skip");

                if (skipNode != null && "true".equals(skipNode.getValue())) {
                    getLog().info("Artifact resolution skipped due to maven-deploy-plugin skip=\"true\" config.");
                    return;
                }
                break;
            }
        }

[bvarner]

Wow. Yeah, that is pretty nasty. I cringed at the Xpp3Dom casts already used to extract plugin configuration in the extensions.

I'm going to think this one through for a few more days before I take action on it.

There are folks that deploy without the maven-deploy-plugin, I'd like to find some way to accommodate that case, too.

[PayBas]

Wow. Yeah, that is pretty nasty. I cringed at the Xpp3Dom casts already used to extract plugin configuration in the extensions.

It's definitely not going to win any beauty contests, I'll give you that ;). It was just a PoC.

There are folks that deploy without the maven-deploy-plugin, I'd like to find some way to accommodate that case, too.

Not sure how you would accommodate that. The plugin needs to know somehow which artifacts it can safely expect to be present for promotion, and which ones are erroneously missing. The plugin already makes accommodations for the maven-deploy-plugin via pluginsToRetain, so giving that (most common) workflow priority makes sense imho.

~~The only way around this that I see is for folks that don't use the maven-deploy-plugin (but do experience this exact issue) to supply an optional list of "artifacts to promote" to the plugin themselves (via a new gitflow-helper-maven-plugin configuration setting in the POM perhaps?). How they wish to fill this list is up to them. The plugin would only need to support the parsing of this list to provide input for a (modified) attachExistingArtifacts().~~

edit: disregard that, artifact promotion is done on a per-pom-basis. Perhaps a simple gitflow-helper-maven-plugin configuration settings to skip promotion on a per-pom-basis would suffice?

[wismax]

Hi, I'm currently facing the same issue, any update on this ? I would be happy to help if I can, if you can give some direction to the recommended options to fix this.

[bvarner]

@PayBas your last suggestion about skipping specific artifacts for promotion by pom -- that would work for your original case too, correct? This sounds more promising, and less specific - deploy plugin-dependent.