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

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

Open
petermcj opened this issue Jan 30, 2019 · 6 comments

Comments

@petermcj
Copy link

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.
@petermcj petermcj changed the title Promote to master doesn't work in multi-module project where some artifact are marked as not to uploaded to the repo Promote to master doesn't work in multi-module project where some modules are marked as not to be deployed to the repo Jan 30, 2019
@bvarner
Copy link
Contributor

bvarner commented Dec 22, 2019

@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
Copy link

PayBas commented Dec 23, 2019

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
Copy link
Contributor

bvarner commented Dec 23, 2019

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
Copy link

PayBas commented Dec 24, 2019

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
Copy link

wismax commented Apr 3, 2020

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
Copy link
Contributor

bvarner commented Apr 3, 2020

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants