I am migrating from Maven3 to Gradle and I have an dependency on an internal project that includes some properties as version identifiers. When I try to compile my project, it complains about the dependency not found. The problem is these properties either use a period '.' or a dash '-' (e.g., cargo.version, supported-spring-version).
Is there a way in Groovy to declare a variable with odd characters?
def 'supported-spring-version' = '3.1.0.RELEASE'
You can't use def, but you can declare them in the current binding
this.'some-string' = '3'
println this.'some-string'
There's probably a better way round this though, but there's not enough information in your question to reliably suggest an alternative
Related
I am experimenting with a blue/green deployment setup for lambdas using terraform and lambda aliases.
I am trying to automatically retrieve the previously deployed version of the lambda by using the aws_lambda_function data source and using the value inside the routing_config => additional_version_weights. This would allow me to set up a traffic split between the previously deployed version and the version that has just been deployed.
However, I have run into 2 errors I don't quite understand.
The first error is when I try and use the data source in conjunction with a regular variable. In this case terraform complains about being unable to parse the value.
If I hard code the value terraform will attempt to run the update, however, it will fail as it tries to set the version in the routing configuration to an empty value which causes a validation error. If I instead output the value I can see that the correct version is retrieved.
Example code and steps to reproduce can be found on link below.
https://github.com/jaknor/terraform-lambda-data-source-issue
Is anyone able to explain why this isn't working?
Please note, while I appreciate that there are other ways of achieving my goal, at the moment I am only interested in understanding these particular errors.
In Terraform v0.11 and prior, interpolation sequences are not supported on the left side of an = symbol introducing an argument or object key.
To generate a map with dynamic keys, you must instead use the map function:
additional_version_weights = "${map(data.aws_lambda_function.existing_lambda_func.version, var.lambda_previous_version_percentage)}"
In Terraform v0.12 (which is in beta as I write this) the parser is now able to distinguish between arguments (which must be constants in the configuration) and map keys (which can be arbitrary expressions) and so the following syntax is preferable, although the above will still work for backward compatibility.
additional_version_weights = {
(data.aws_lambda_function.existing_lambda_func.version) = var.lambda_previous_version_percentage
}
The additional parentheses around the key expression are important to tell Terraform that this should be understood as a normal expression rather than as a literal name.
My build complains about a missing dependency:
... requires bundle org.eclipse.ui [3.106.0,4.0.0)' but it could not be found
The used target platform points to a P2 location that includes the following JAR: org.eclipse.ui_3.106.0.v20140812-1751.jar
Still the build fails and raises the following two questions:
I thought 3.106.0.v20140812-1751 would be in the range [3.106.0,4.0.0), is that not true?
How does OSGi handle the fourth part of a version? If 3.106.0 is a valid version, then how is the suffix .v20140812-1751 understood by OSGi?
A link to a good explanation of OSGi versioning would also be highly appreciated.
I thought 3.106.0.v20140812-1751 would be in the range [3.106.0,4.0.0), is that not true?
Yes it is true.
How does OSGi handle the fourth part of a version? If 3.106.0 is a valid version, then how is the suffix .v20140812-1751 understood by OSGi?
The fourth part is just a segment like any other except that it is sorted alphanumerically rather than purely as a number. The specific algorithm is String.compare(), so you should read the standard JavaDocs for that method to get the full details. This segment is called the "qualifier"
In version 3.106.0.v20140812-1751, the qualifier is v20140812-1751. In the version 3.106.0, the qualifier is the empty string. As the JavaDocs for String.compare() will confirm, any non-empty string sorts after the empty string.
Is there a way to perform conditional execution of snippet in pom.xml?
my requirement is to copy a file/directory to deploy structure based on variable defined in pom.xml...
eg:
< if >
< equals arg1="package" arg2="package"/>
< then>
....
< /then>
< /if>
Not sure how can I achieve this!
Any pointers would be highly appreciated.
Thanks,
SR
Probably you'll need to use Maven AntRun Plugin for that.
In general, there's no conditional expressions in POM. The only thing similar somehow to this are build profiles that can be activated on some specified conditions, however they probably don't fit into your current case.
And, at the end, my suggestion here. We don't know exactly what your case is about and don't even have any real code snippet, however from my experience it's really unusual to have to use such hackin' stuff in Maven. For me it smells like some problems with Maven understanding, project structure or stuff like that. I may be wrong and maybe your case really needs that, but consider other options to fit into Maven default approach and conventions instead.
Well, you can use Maven's profiles, to do that.
Or you can take a look at Maven's Ant Tasks.
I'm trying to figure out if what Maven's policy is on custom qualifiers. I know that there exists specific qualifiers in Version strings that maven checks for, such as:
1.0.0-SNAPSHOT
5.3.0-beta-5
etc, but I was wondering if I could write specific rules or something that could handle custom qualifiers, such as:
1.0.0-mybranch
5.3.0-myotherbranch
or how maven would deal with such version strings. I've tried them out and things seem to be ok, I'm just wondering if Maven has some custom logic that could be used.
Thanks!
These examples will work fine.
Qualifiers have no special meaning other than:
SNAPSHOT, which gets transformed into the correct timestamp / build number
solely numerical values, which are actually a build number instead of a qualifier (and considered newer than the corresponding base version)
All qualifiers are considered to be older than the associated release, i.e. 1.2-beta-1 < 1.2
Comparison of qualifiers is done as a string comparison. This behaviour can differ in Maven 2.x and Maven 3.x (in the former, 1.0-beta-10 < 1.0-beta-5, in the latter it behaves in the reverse as you'd expect).
The 2011 answer is now obsolete in many important details. See the Javadoc on https://maven.apache.org/ref/3.3.9/maven-artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html and the Wiki link there for the current version processing logic.
c.f. How does maven sort version numbers? for commentary on the Javadoc for ComparableVersion.
If I have an identifier with a same name as existing keyword, how do I escape it?
That's what I found (and this is probably the final answer):
It is possible to use # as a prefix in identifier names. However, by default it creates a different identifier (#a != a).
Since # is allowed, it is possible to add a new compiler step to the pipeline that will do TrimStart('#') on all identifiers. It works ok, you will just have to remember all types of things that have names.
If you are using Rhino.DSL, it has a UseSymbols step that converts #a into 'a', which had confused me a lot (I was working with project that included this step by default).
I don't think anything like the C# # prefix is implemented in Boo... but I'm pretty sure it could be achieved by inserting a custom compiler step to the beginning of the compiler pipeline.