To configure a component I need to add --enable-feature into EXTRA_OECONF_somename
So I tried to do:
EXTRA_OECONF_append_somename = --enable-feature
But it did not help. After investigation it was found that the one of the third-party recipe contains the following line:
EXTRA_OECONF_remove_somename = --enable-feature
I can't modify the third-party recipe.
Is there a way to add --enable-feature into EXTRA_OECONF_somename
Thank you.
I'm afraid not. The _remove operations are always applied last so there is no way to undo them. I would say that the original recipe shouldn't be using it - _remove is intended for distro policy where you want to say "I don't care how this item got in the value, just remove it".
For preference the original recipe should instead it should be using PACKAGECONFIG to control addition (or not) of this feature.
Related
Is the property "health.config.enabled" still valid and being processed in current Spring Cloud?
If yes, where in the code it is being done?
The property is in the current official documentation and has worked well for me so far (in cloud clients).
But as a whole string, it cannot be found anywhere in the current source code (besides the doc source).
For me as a beginner, it was easy to find in the old version of ConfigClientAutoConfiguration.java
Recent version of ConfigClientAutoConfiguration.java does not contain that whole property name, although I guess it's still being processed but in a more abstract way that I don't understand yet. Thus I'd appreciate even a hint in the form of "what used to be done on line "#ConditionalOnProperty(value = "health.config.enabled", matchIfMissing = true)" before is now roughly done on line XY".
Thanks.
It is replaced by #ConditionalOnEnabledHealthIndicator("config") (see here).
From the javadoc for that annotation
Blockquote
#Conditional that checks whether a default health indicator is enabled. Matches if the value of the management.health.<name>.enabled
So the new property is management.health.config.enabled
For a variety of reasons too convoluted to explain here, I find myself in a position where I need to be able to remove custom code workflows, while leaving the solution there.
I essentially have the same code as the plugin registration tool
Namely
service.Delete("plugintype", new Guid(info));
where info is the workflow id [running on a foreach loop but that's beside the point]
However, while the tool removes the workflows without any issues, my code complains about dependencies.
EM:
Additional information: The PluginType(a0b2dcf7-cf2a-111e-7da9-003021880a42) component cannot be deleted because it is referenced by 1 other components. For a list of referenced components, use the RetrieveDependenciesForDeleteRequest.
which I duly did
RetrieveDependenciesForDeleteRequest req = new RetrieveDependenciesForDeleteRequest();
req.ComponentType = 90; //plugintype
req.ObjectId = new Guid(info);
RetrieveDependenciesForDeleteResponse resp = (RetrieveDependenciesForDeleteResponse)OrgService.Execute(req);
This retrieves an optionvalueset, but there is little I can do with it as I cannot remove it from the solution as the solution is managed.
The only difference I can see is the way the OrganizationServiceProxy gets instantiated. The plugin registration tool includes a way to refresh the securitytoken, but as far as I can tell it's not doing much (I've stepped through the code, but it's possible I missed something)
Are you sure that it is an OptionSetValue that is the dependency? It's much easier to use GUI to determine what the dependencies are. Fire up your solution in CRM 2011, click 'plug-in assemblies', select the relevant assembly then go through each custom workflow/plugin item and click 'Show Dependences'.
In my case I had another workflow (created within CRM) that was referencing a custom workflow preventing removal of the assembly.
You won't be able to remove components from a Managed solution... Are you the author of the solution originally?
As an aside, does your workflow fire on change of the OptionSet that is showing as a dependency?
I'm trying to add the item
<key>UIStatusBarHidden</key><true/>
to my plist that's auto-generated by CMake. For certain keys, it appears there are pre-defined ways to add an item; for example:
set(MACOSX_BUNDLE_ICON_FILE ${ICON})
But I can't find a way to add an arbitrary property.
I tried using the MACOSX_BUNDLE_INFO_PLIST target property as follows: I'd like the resulting plist to be identical to the old one, except with the new property I want, so I just copied the auto-generated plist and set that as my template. But the plist uses some Xcode variables, which also look like ${foo}, and CMake grumbles about this:
Syntax error in cmake code when
parsing string
<string>com.bedaire.${PRODUCT_NAME:identifier}</string>
syntax error, unexpected cal_SYMBOL,
expecting } (47)
Policy CMP0010 is not set: Bad
variable reference syntax is an error.
Run "cmake --help-policy CMP0010"
for policy details. Use the
cmake_policy command to set the
policy and suppress this warning. This
warning is for project developers.
Use -Wno-dev to suppress it.
In any case, I'm not even sure that this is the right thing to do. I can't find a good example or any good documentation about this. Ideally, I'd just let CMake generate everything as before, and just add a single extra line. What can I do?
Have you looked into copying the relevant *.plist.in file in /opt/local/share/cmake-2.8/Modules (such as MacOSXBundleInfo.plist.in), editing it to put <key>UIStatusBarHidden</key><true/> (or #VAR_TO_REPLACE_BY_CMAKE#), and adding the directory of the edited version in the CMAKE_MODULE_PATH?
If you have CMake installed as an app bundle, then the location of that file is /Applications/CMake.app/Contents/share/cmake-N.N/Modules
You can add your values using # and pass #ONLY to configure_file.
Unfortunately there is no simple way to add custom line to generated file.
I tried using aegis -change_attributes to change the brief_description of my current change set but it didn't work.
aegis -change_attributes description="test"
What should I do to make this work?
EDIT: The command I was looking for was
aegis -change_attributes brief_description="$DESC";
Since no answer was given (for quite some time) I'm adding the solution I gave in the comments, as the anser:
The above command is correct if you want to set the extensive description. If one wants to just set the brief description "aegis -change_attributes brief_description="$DESC"" has to be used
For example, instead of writing the following:
element * .../my_branch_01/LATEST
element * .../base_branch/LATEST -mkbranch my_branch_01
I would want to write something like this:
MY_BRANCH=my_branch_01
element * .../%MY_BRANCH%/LATEST
element * .../base_branch/LATEST -mkbranch %MY_BRANCH%
Is this even possible? What is the correct syntax?
The only native way to do this in ClearCase is to use attribute within a config-spec.
According to the version selector rules, you can make a "selection by query" rule, based for instance on an attribute:
element * ...{MY_ATTRIBUTE_NAME=="aValue"}
would select the LATEST version on any branch with an attribute 'MY_ATTRIBUTE_NAME' with 'aValue' in it.
That mean you need to change the attribute value on the old branch, put it on the new branch, 'cleartool setcs' your view again, and you should have a new content based on a new version selection.
Not very straight forward, but it could work, except for the mkbranch part (which needs a fixed name).
Regarding GeekCyclist's answer, a few comments:
The solution to include a common config spec can work for Base ClearCase solution, but:
need to be in a share available by all concerned developer
the setcs is indeed necessary to Ccuses the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec in the view storage directory. This includes:
Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
Reevaluating –config rules, possibly selecting different derived objects than previously
Re-reading files named in include rules
all the other developers need to be notified when the common included config spec file changes (there is no native notification included in ClearCase)
If you need to have one "environment" (i.e. one "view" or workspace) with a variable content (depending on a different branch), you need to define a symbolic link (or a windows subst) pointing to different views (each with their own config spec)
That way, you only have to change the link (or the path subst'ed) in order to change the config spec associated with a given fixed path.
It's been a while since I worked in ClearCase (we switched to Subversion), but if I recall correctly there is no way to do this native to ClearCase.
You could use or write a script generator that would create your spec file and then include that in the actual spec:
element * CHECKEDOUT
include scripted_file_output
Then run
cleartool setcs -current
The problem with this approach is that I believe the include spec would need to be regenerated and the cleartool setcs run whenever you change the value of MY_BRANCH.