-
Notifications
You must be signed in to change notification settings - Fork 11
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
Added configuration parameter lockDir to specify where proto.lock lives #16
Conversation
Thanks for the contribution! Before we can merge this, we need @seime to sign the Salesforce.com Contributor License Agreement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious, what prompted the need for this change?
@@ -189,15 +195,33 @@ public void execute() throws MojoExecutionException, MojoFailureException { | |||
options = ""; | |||
} | |||
|
|||
Path lockFile = Paths.get(protoSourceRoot, "proto.lock"); | |||
if (options.toUpperCase().contains("--LOCKDIR")) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Move this new code section to a private method that returns the lockDir
. It's not your fault that execute()
is getting really hairy, but it's time to start breaking it into methods.
} | ||
|
||
// Build option for lock file location | ||
String _lockDir = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: There has to be a better variable name than _lockDir
.
We generate some proto descriptors from xml schema, and as with all generated sources/resources we place them in the (maven) target folder before packaging and deploying them as jar files. The plugin was hardcoded to always look for proto.lock inside the proto source folder, and if not found it would just renitialize a new proto.lock there each time. Even if --lockdir would be specified the maven plugin wouldn't honour that and just renitialize a new proto.lock inside the temp folder. This caused changes silently to be accepted (except for a log statement saying that it was initialized) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the extra refactoring!
Released in 1.0.6 |
Passing
<option>--lockdir=somewhere_else</option>
does not work, the plugin always checks the proto root directory forproto.lock
.This PR adds a new configuration parameter
lockDir