Given a build.sbt which is committed to a code repository, what is a general pattern which allows users to override setting values defined in this script?
On the surface, this appears to have been answered in Where should local settings (per user, and not version-controlled) go in newer (0.10+) versions of SBT?. The answer there is to simply define two scripts in the same directory -- build.sbt and local.sbt, and rely on the fact that sbt will combine these scripts together. This may work for augmenting values (i.e., appending lists), but I don't see how it works for overriding the script value, since if a setting's value is set in both scripts, I don't know which of the two values will survive after sbt has combined the scripts.
It could be that I'm missing something very simple.
I'd recommend using ~/.sbt/0.13 global directory where your .sbt files are processed during project load and after the other files in the project itself.
I found ~/.sbt/0.13/global.sbt a good place for global settings - the name always hints me for its purpose.
Related
I have a doubt over this question
Question: What is the correct order of precedence to setup runmodes in aem? (From left to right, left beign the highest)?
A. System property, Sling properties file, jar file
B. jar file, sling properties file, system property
C. Sling properties file, jar file, system property
D. jar file, System property, Sling properties file
Answer : B
I had gone through various docs and had done multiple experiments over this.
Acc to Adobe documentation the order is - Sling.properties, System property, jar file
Similarly, this Adobe doc has a contradictory opinion - jar file, sling.properties, system property
Also, Apache Sling Doc says that any property to option D (-D) set in manner, n=v, overwrites same named properties in the sling.properties file. which means system property has higher precedence then sling.properties.
Now, these are all according to docs, what I had experimented is-
I made a path ${dir}/crx-quickstart/conf and created a file sling.properties and wrote sling.run.modes=publish. Then renamed the jar file as cq-author-7502.jar. Then run this jar with the command java -jar cq-author-7502.jar -Dsling.run.modes=prod
This is my observation:
1. When the jar runs, Setting 'sling.run.modes' to 'publish' from sling.properties. this message is shown in the terminal.
2. The instance up in author mode. And
3. When I checked the instance-mode in felix console, it was prod
I am totally confused about the order of precedence. As everything seems contradictory to me.
It would be grateful if anyone can put some light on it..
Thank you
I think it depends on when we are checking the run mode precedence, at the time of installation or later on a running instance and how we are starting our instance. There are 2 kinds of run modes. Installation time run mode, custom run modes.
Installation time run mode - As explained by official run modes documentation and setup instructions, this can be set only one time at the time of installation. This includes author,publish,nosamplecontent,samplecontent
Custom run mode - Own customized run modes e.g. dev, qa, prod etc
I did some tests (AEM 6.1), precedence is working in following way
Initial setup
Start jar (by double clicking) - In this you do not have option to set run mode in sling.properties, start script first time. JAR name takes precedence.
Unpack jar and specify run mode as system properties in start script - JAR name doesn't comes to picture here. In this you do not have option to set run mode in sling.properties. System properties takes precedence.
Running instance
Even if we change run mode in JAR name, it doesn't changes the installation time run mode. For custom run mode, JAR file name is not applicable. Order of precedence is sling.properties -> specifying -r option (command line jar option) -> system properties (start script)
As far as the question (seems to be AEM certification question), the context is not clear with respect to which they are asking. Helpx article is contributed by community, context might be different. Sling documentation link (it seems as per this link the launchpad version in AEM is old, not 2.4.0). Need to ask Adobe to confirm :).
There are two conflicting Adobe articles that say something quite different
Article 1: (Assumed more recent)
Starting CQ with a specific run mode If you have defined
configurations for multiple run modes then you need to define which is
to be used upon startup. There are several methods for specifying
which run mode to use; the order of resolution is:
sling.properties file
-r option
system properties (-D)
Filename detection
From this Reference: Configure Run Modes
- the answer is C
Article 2:
Behavior when run modes are specified more than one way The run mode
specified in the naming of the jar file takes precedence. If run modes
are not specified in the naming of the jar file, the values in the
sling.properties file are used. If run modes are not specified in
either the naming of the jar file or the sling.properties file, the
system property (or JVM argument) is used.
From this Reference: Configure Run Modes
- the answer is B
However based on my experience and based on process of elimination I'd go with answer B.
I'm a bit of a newbie, but already running apps with Meteor.js. Since I'm now working with API keys I'm finally realizing that security is a thing, and so I placed my keys in a settings.json, and am instructed not to commit, or to .gitignore the file. But despite reading the documentation, this all seems very counter-intuitive. If I need the variables to make my HTTP requests, then how can my app possibly function without adding my keys, in some form, to the repo? I know the answer is "it can," but how? (in general terms, I don't need a Meteor specialist yet) .
Typing this question out makes me feel pretty ignorant for the stage I'm at, but the docs out there for some reason are not clarifying this for me.
You can generate the file with sensitive information on git checkout.
That is called a smudge script, part of a content filter driver, using using .gitattributes declaration.
(image from "Customizing Git - Git Attributes", from "Pro Git book")
That 'smudge' script( that you have to write) would need to:
fetch the right key (from a source outside the repo, that way no risk to add and push by mistake)
generate the settings.json, using a tracked manifest template settings.json.tpl with placeholder value in it to replace.
That means:
the template settings.json.tpl is added to the git repo
the generate file settings.json is declared in the .gitignore file and never versioned.
I usually follow the unofficial Meteor FAQ on how to structure my codebase, but I can't figure out where I should put my global constants.
To give an example: I have some database entries with a constant GUID that I need to reference in many points of my app. So far I just attached the constants to the relevant collection, such that in collections/myCollectionWithGuids.coffee it would say:
#MyCollectionWithGuids = new Meteor.Collection "myCollectionWithGuids"
#MyCollectionWithGuids.CONSTANT_ID = "8e7c2fe3-6644-42ea-b114-df8c5211b842"
This approach worked fine, until I need to use it in the following snippet, located in client/views/myCollectionWithGuidsView.coffee, where it says:
Session.setDefault "selectedOption", MyCollectionWithGuids.CONSTANT_ID
...which is unavailable because the file is being loaded before the Collections are created.
So where should I put my constants then, such that they are always loaded first without hacking in a bunch of subdirectories?
You could rely on the fact that a directory names lib is always treated first when it comes to load order.
So I would probably advise you to organize your code as follow :
lib/collections/collection.js
client/views/view.js
In your particular use case this is going to be okay, but you might find cases when you have to use lib in your client directory as well and as the load order rules stack (subdirectories being loaded first), it will be loaded BEFORE the lib folder residing in your project root.
For the moment, the only way to have full control over the load order is to rely on the package API, so you would have to make your piece of code a local package of your app (living in the packages directory of your project root).
It makes sense because you seem to have a collection and a view somehow related, plus splicing your project into a bunch of collaborative local packages tends to be an elegant design pattern after all.
Creating a local package is really easy now that Meteor 0.9 provide documentation for the package.js API.
http://docs.meteor.com/#packagejs
I would put your collection definitions in a lib directory. File structure documentation explains that all files under the lib directory get loaded before any other files, which means your variable would be defined when you attempt to access it in your client-side code.
Generally speaking, you always want your collections to be defined before anything else in your application is loaded or executed, since your application will most likely heavily depend upon the use of the collection's cursor.
I use an ivysettings.xml file to configure the repositories to use for sbt, which uses Ivy.
However, it's not able to download a particular snapshot which uses unique naming (i.e. date-based naming). It only tries the patterns listed explicitly in my ivysettings.xml file (which makes sense), so it can't see the details in maven-metadata.xml which tell it the filename of the snapshot jar to download.
I tried specifying the version explicitly instead of as a snapshot in Build.scala:
"com.jolbox" % "bonecp" % "0.8.1-20131105.191813-1"
(which would be my ideal solution, because then it would be cached in our maven repository and I'd be guaranteed to always use the same snapshot), but this generated the wrong URL (there should be an 0.8.1-SNAPSHOT in there, but of course there isn't):
http://maven/nexus/content/groups/softwaretools-snapshot-group/com/jolbox/bonecp/0.8.1-20131105.191813-1/bonecp-0.8.1-20131105.191813-1.pom
I then tried specifying the URL explicitly using from, but this didn't work.
I then tried using latest.integration as the version, but that didn't correctly identify the latest version - it thought it was 0.8.0-rc1, which is clearly wrong.
Download the dependency manually and add it to the lib directory of the project (create it if necessary); remove it from the Build.scala file.
in my project, I want to refer to an other xcconfig file, located in InDesign SDK. As this SDK may be installed at different locations, depending upon the machine, I prefer to declare an environment variable for locating it.
Nest step is obviously to use variable (aptly named ID_CS5_SDK_DIR) in my xcconfig include directive.
Unfortunatly, when I try the simple
// InDesign sdk project build settings (based on common build settings)
#include "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
XCode throws me a
[WARN]AutocatPlugin.xcconfig line 7: Unable to find included file "$(ID_CS5_SDK_ROOT)/build/mac/prj/_shared_build_settings/common.xcconfig"
How can I make it work ?
I've been trying to do this too and also came to the conclusion that it is not possible.
I once tried to achieve that and came to the conclusion that you can't. I would be happy if someone proves us it's possible though then delete my answer
It seems like .xcconfig files can only DEFINE and set value to environment variables (which prevail only throughout the build session) but not USE or evaluate environment variables.
Maybe it is because .xcconfig files serve as a base layer of build-settings, and are not parsed.
Unfortunately this is not possible, but instead of making one include the other, you can use two different xcconfig files per target. Just select one for the Project and one for the Target.
If you put the environment variable in /etc/config/launchd.conf and then reboot it will be accessible to the .xcconfig file.
Short Instructions for experienced users:
Edit the read-only file /etc/launchd.conf and add 'setenv VARIABLENAME /FOLDER/PATH' to the file, then reboot.
Steps For Inexperienced Users
Open Application/Utilities/Terminal, and entersudo nano /etc/launchd.conf
Create the Environment Variable by adding a line like setenv VARIABLENAME FOLDER/PATH and then pressing ENTER.
Save the file using Ctrl-O, Ctrl-M, (Possibly Ctrl-Y to overwrite), then Ctrl-X to exit the editor.
(Optional) type cat /etc/launchd.conf to see that your changes are present
Restart your computer. (Logoff doesn't work)
You can now access the variable in your .xcconfig file as$(VARIABLENAME)
Notes:
This creates a GLOBAL environment variable, accessible to all users. It probably doesn't make sense to set this to something in your home directory (e.g ~/MyFolder). If you do this, however, you need to use the full pathname, such as /Users/MyUserName/MyFolder).
References:
Stack Overflow - Setting Environment Variables in OSX
Stack Overflow - Are there any differences between /etc and /private /etc