-
Notifications
You must be signed in to change notification settings - Fork 301
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
Unable to obtaing git.branch property #287
Comments
By default the plugin doesn't expose the properties into the maven cycle. |
Here is my current configuration
with this property
but I'm still having the variable unresolved
|
Mhh that is somewhat strange.
mvn clean package -Pdemo will result in a jar called can you do the following:
|
Hello,
After added the flag you asked, here is part of the generated output
The
|
Based on the feedback it seems that the plugin itself can retrieve the information.... How do you invoke the GCLOUD (that currently has the error with the bad value)?
If it is a file i would double check if the file is getting filtered. Use something like this for debugging purposes:
|
Gcloud is a Maven Plugin which is launched with goal
The So I can say that the it gets the values from the pom itself. It seems like the property is not well handled So I tried to use directly the property values inside the configuration
But i'm getting the same error |
can you provide an example project where i can reproduce this? What is the output of
|
I'm attaching you a sample project with all the plugins configured In order to use this, I created a simple git repository (only local) and set the HEAD to master (with only 1 commit). To invoke the gcloud goal you can use " If everything is configured correctly, you should see this Maven log
The output of the antrun-plugin is
|
Well this is somewhat really strange....Currently I can reproduce the problem but don't understand what it is caused by.... I thought it might be a Maven internal Problem where the @Parameter-Annotation is broken again and created a sample Maven-Project that uses the same stuff as the app-engine (https://github.com/GoogleCloudPlatform/app-maven-plugin/blob/master/pom.xml) Just for future reference can be executed by: Download project here: I'll update once I have something more concrete.... |
Ok just as a follow up....I cloned the app-maven-plugin from git and introduced some debugging code to verify what is going on.... The Mojo-Class that is being used for In https://github.com/GoogleCloudPlatform/app-maven-plugin/blob/master/src/main/java/com/google/cloud/tools/maven/DeployMojo.java#L142 we have the getter-method that retrieves the parameter:
So far this is pretty much default stuff. Now the interesting observation....when using the suggested command it doesn't seem to replace the Maven-project properties no matter what. However when changing the plugin-Definition inside the pom.xml to the following:
and executing TL;DR,When calling the Maven-Plugin via the Plugin's Prefix and goal I'll report this to Maven and link as soon as I can remeber my password. |
Maven Sample project to reproduce the issue:
Maven Bug Report: |
Any update on this issue? |
@NicolaSpreafico unfortunately there is no update on the Maven Issue. |
Wih the suggested workaround seems to be working fine
And launching
This is not optimal because the Maven build is executed twice (one for the install goal and once again when the deploy goal is triggered) but while the Maven issue (hopefully) will be solved, I can live with that. Here is the correct generated command This workaround of yours seems to be working just fine with all the other plugins/configuration of the project, from a couple of tests I made is ok. |
@NicolaSpreafico if the double build really turns out to be a problem try to to set your configuration to use the deploy-phase as well - AFAIK this should solve this. My configuration is just a suggestion. Another workaround (basically based on #287 (comment)) would be using the following: Unfortunately this bug also applies for other plugins and is not limited to the maven-git-commit-id-plugin.Since its a Maven-Bug (or at least how Maven currently works) I can't provide a fix for it. |
Thank you for the additional details, this method is much easier. But in my specific case, I already using Eclipse launch profiles (because I'm using Eclipse IDE for development). This is an example of .launch file
I'm using this profile due to a issue of At the end I simply added your suggestion for the revision goal into the For my case this second solution is much better that before, I now removed the execution configuration from the plugin and it seems to be working fine. |
Thanks for the feedback! In this case it seems to be easier to have it configured within the Eclipse IDE as additional launch profile. If there anything not working with the suggested workaround please let me know. |
Using your suggested configuration (I tried just as a test) I'm getting an error
This is strange because if I use the full package |
Sorry just double checked. Based on the generated |
Correct, now is working fine I also removed the
node from plugin configuration in pom.xml considering that the revision goal is triggered by hand on the maven launch |
Sorry, wrong button. I used "Close and Comment " instead of "Comment" |
any news? |
Hi, So in short, sorry if you still have this issue.... |
Hello, |
Hi, from my side there is no update and sadly I can't do anything about it. Unfortunately I only can refer to the ugly workarounds: |
Hi, |
Thanks for the alert! Based on the comment I understand why this is issue is happening now, I asked if there is a workaround available (based on the comments it seems unlikely)..... Note for myself (possible dirty hack workaround):
see also |
Thank you, I understand that, while for this case the workaround is still appliable, with #413 there is no easy solution. As far I understood about all this case, this is something that need to be fixed at Maven level, not with third-parties plugins. |
At the current stage I would say it certainly would be good and the right thing if it would be fixed at Maven level. However I honestly don't expect that to ever happen and if it happens I would expect it to only apply for a newer version of maven. Updating this plugin to this version would then potentially break the ability to use the plugin with older maven versions, which is something not desirable. The stackoverflow links I posted are essentially links I found that potentially could used by third-parties plugins (like this plugin) to "fix" the problem. I currently didn't had the chance to perform further testing, so I currently can't say if this would be a feasonable approach. To the question if this would be ugly as hell, I would respond yes, but we are using maven after all... I have some more time later or on the weekend to perform a better insight :-) Edit: @Override
protected void executeMojo() throws MojoExecutionException {
getLog().warn("=====================================================================================");
getLog().warn("executeMojo: " + getClass().getCanonicalName());
project.getProperties().put("sample.generated", "Hello world!");
for (final Plugin p: project.getBuild().getPlugins()) { // project.getBuild().getPlugins() VS project.getBuildPlugins()
getLog().warn("+++++++++++++++++++++++++ plugin: " + p.getArtifactId());
Object rawConfig = p.getConfiguration();
if (rawConfig != null) {
getLog().warn("RAW: " + rawConfig);
// getLog().warn("\t\t\t" + rawConfig.getClass());
if (rawConfig instanceof org.codehaus.plexus.util.xml.Xpp3Dom) {
traverse((Xpp3Dom) rawConfig);
}
getLog().warn("UPDATED: " + p.getConfiguration());
}
p.setConfiguration(rawConfig);
}
getLog().warn("=====================================================================================");
}
private void traverse(Xpp3Dom root){ // @Nullable
if (root != null && root.getChildren() != null) {
for (Xpp3Dom child : root.getChildren()) {
// getLog().warn("\t\t\t name=" + child.getName() + " / value = " + child.getValue());
if (child.getValue() != null) {
child.setValue(child.getValue().replaceAll("\\$\\{sample.generated\\}", "Hello world!"));
}
traverse(child);
}
}
} reports
|
Thank you, |
Please refer to #413 (comment) for the difference between the SonarQube issue and this one. Since there is not much I can do to fix this (as per comment in the maven issue) I only can refer to the available workaround or suggest to open a ticket with the appengine plugin to have some sort of functionality that makes such behaviour possible. Sadly from the perspective of the plugin I nothing left besides closing this as |
Hi,
I discovered your plugin from here: https://stackoverflow.com/a/13975553
My goal is very simple, having the git branch name inside the build version.
Here is I come so far
And then the property
<deploy.version>test-${git.branch}</deploy.version>
But the variable is not resolved
[DEBUG] (f) version = test-${git.branch}
Am I missing a basic configuration?
I tried to launch the
pl.project13.maven:git-commit-id-plugin:revision
goal manually and there is no error
Because my filesystem is like this
I also added this configuration, but no changes
I also tried to generate the external properties files in order to see if the data is properly gathered from my repo, but no file is created
Tha main problem here is that I'm not seeing any error, so I'm going a little blind understanding the problem.
Thanks
The text was updated successfully, but these errors were encountered: