Most of our client projects have a very similar starting point:
Pristine AWS account used only for a single environment for this application
GraphQL API and a basic model to start with
A REST API with an OAuth handler endpoint and a generic webhook listener endpoint, each with a corresponding Lambda function (with code for each)
I've created this basic amplify app and I want to create a repo with this general structure as a starting point for future projects. The idea being that I'd copy the contents of the repo when starting a project and build from there.
So I've copied the entire amplify directory over to a new location, removing everything that is in the amplify section of the .gitignore file, and I have a folder structure like this:
My steps to start a new project are:
Create a new directory
Copy the template repo files into this directory
run amplify init
Once I do that, it creates two additional files:
amplify/.config/project-config.json
amplify/team-provider-info.json
Then, I try to do amplify push -- but I get No changes detected.
I'm not even sure if what I'm doing is possible -- I was wondering if anyone else has tried this?
I tried to follow the steps given in the below WSO2 documentation link to customize the APIM management console's interface but the changes don't reflect after restarting the carbon server. Need suggestions on this.
Documentation link: https://apim.docs.wso2.com/en/latest/install-and-setup/setup/advance-configurations/customizing-the-management-console/#!
Steps followed as per documentation:
Copied the org.wso2.carbon.ui_4.6.0.jar from <PRODUCT_HOME>/repository/components/plugins/ to a separate location.
Created a MMP with name org.wso2.carbon.ui_4.6.0_patch and added new css file and image file under the MMP. Copied the template.jsp from the org.wso2.carbon.ui_4.6.0.jar and placed it under this MMP project. Within this jsp file, reference of the new css file was added.
Created one more MMP with name org.wso2.carbon.ui_4.6.0_fragment and within its pom.xml added a plugin to point to the org.wso2.carbon.ui_4.6.0_patch MMP.
Created jars for both the MMPs' using maven and copied them under <PRODUCT_HOME>/repository/components/dropins/.
Restarted the WSO2 APIM server but the changes didn't reflect in the management console (https://localhost:9443/carbon) as given in the documentation.
Please follow the instructions given in documentation [1]. The document that you have pointed out has to be updated.
[1] https://is.docs.wso2.com/en/latest/setup/customizing-the-management-console/#customizing-the-management-console
I am trying to modify the PathMappings of the "CMISChangeLog" audit application bundled out-of-the-box in Alfresco 5.
I have found these PathMappings in alfresco-audit-cmis.xml which can be found in Alfresco's source code, so I modified this XML file and put it into tomcat/shared/classes/alfresco/extension/audit/alfresco-audit-cmis.xml (thinking that would override the out-of-the-box application) before restarting Alfresco. Problem:
ERROR [audit.model.AuditModelRegistryImpl] Failed to load audit model: file:/home/nico/alfresco/tomcat/shared/classes/alfresco/extension/audit/alfresco-audit-cmis.xml
org.alfresco.repo.audit.model.AuditModelException: 00120000 Audit application key 'CMISChangeLog' is used by: AuditApplication[ name=CMISChangeLog, id=3, disabledPathsId=381]
at org.alfresco.repo.audit.model.AuditModelRegistryImpl$AuditModelRegistryState.cacheAuditElements(AuditModelRegistryImpl.java:646)
How to override this out-of-the-box audit application?
Grepping through my server I found out that the default audit application's XML file is stored at alf_data/contentstore/2017/12/22/18/23/82dfdccd-6ab9-4091-8b7c-d37d4bcf1627.bin but I haven't found it in the Node Browser:
Note: I don't want to create a new audit application. I must modify the existing one (because I want Alfresco's CMIS ChangeLog to take into account more events).
The XML file is actually in alfresco-repository-5.2.g.jar, which itself can be found in Alfresco's WAR file.
So, if you have an already running Alfresco server, here is the procedure:
Stop Alfresco
mkdir -p /tmp/unjar
cd /tmp/unjar
unzip $ALFRESCO/tomcat/webapps/alfresco/WEB-INF/lib/alfresco-repository-5.2.g.jar (adapt for another version number if necessary)
Do the modifications you want inside the extracted file alfresco/audit/alfresco-audit-cmis.xml
zip -r ../alfresco-repository-5.2.g-custom.jar *
cp ../alfresco-repository-5.2.g-custom.jar ALFRESCO/tomcat/webapps/alfresco/WEB-INF/lib/
Restart Alfresco
For a build run in artifactory, exists a tab named "Environment" which contains a section named "System Variables".
Link to image: Environment tab with variables
I need to add some properties there via REST API or artifactoy groovy public api (PAPI).
I managed to create build info with properties (via REST API), but now I need to update it with the properties. Is this possible?
The Environment tab is created according to the build-info JSON deployed to Artifactory using the /api/build REST API. The build-info structure is available at the build-info github project's README file here:
https://github.com/JFrogDev/build-info
When building the JSON you can add properties to it, by adding them to the "properties" section as described in the the above README. This is probably how you added the properties to the build run.
The build-info for a specific build run however is immutable in Artifactory and cannot be modified after it is deployed.
I am fighting with Xcode 4 workspaces. Currently Xcode 4 wins. Thus, my situation:
I have the workspace with the iOS app project. There is also static library project iOS app depends on in the this workspace.
Solution #1
I try to configure like this:
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(TARGET_BUILD_DIR)/usr/local/include $(DSTROOT)/usr/local/include;
the static library project:
add some header files to target's Build Phases > Copy Headers > Public;
set SKIP_INSTALL to YES.
And important thing: both projects must have configurations named the same. Otherwise, if I have, e.g., configuration named Distribution (Ad Hoc) for the app and Release for the static library, Xcode can't link the app with the library.
With this configuration archiving results to an archive with the application and public headers from static library projects. Of course, I am not able to share *.ipa in this case. :(
Solution #2
I have also tried another configuration:
Xcode preferences:
set source tree for the static library, e.g, ADDITIONS_PROJECT;
the app project:
add to target's Build Phases > Link Binary With Library a product (libmystaticlib.a);
set USER_HEADER_SEARCH_PATHS to $(ADDITIONS_PROJECT)/**;
the static library project:
don't add any header files to Public!;
set SKIP_INSTALL to YES.
I still need to care about configuration names for both projects. But in result I can build and archive successfully. In the result I get archive and I can share *.ipa.
I don't like the second solutions, because in this case I don't get any real advantage of the Xcode 4 workspace. The same effect I can add get, if I add the static lib project inside the app project. Therefore, I think something is wrong with my solution.
Any suggestion how better to link a static libraries?
I also found a solution that works with build and with archive.
In your static library set the Public Headers Folder Path to ../../Headers/YourLib
In your app config set the Header Search Paths to $(BUILT_PRODUCTS_DIR)/../../Headers
In your app you will be able to code #import <YourLib/YourFile.h>
Don't forget the Skip Install = YES option in your static lib.
We've found an answer, finally. Well, kind of. The problem occurred because Xcode 4 places public headers into InstallationBuildProductsLocation folder during build for archive. Apparently, when archiving it sees the headers and tries to put them into archive as well. Changing Public Headers Folder Path of the lib to somewhere outside of InstallationBuildProductsLocation, for example, to $(DSTROOT)/../public_folders and adding this path to Header Search Path solve the problem.
This solution doesn't look very elegant, but for us it seems to be the only option. May be you'll find this useful.
Here is a solution a get from Apple DTS. I don't like it, because it is suggests to use absolute path. But I still publish it here, maybe someone feels it is right for him.
How to set up the static library:
Add a build configuration named "Archive" by copying the Release Configuration.
Move your headers to the Project group of the Copy Headers build phase.
Set the Per-configuration Build Products Path of the "Archive" configuration to $(BUILD_DIR)/MyLibBuildDir. Xcode will create the MyLibBuildDir folder inside the BuildProductsPath, then add your static library into that folder. You can use "MyLibBuildDir" or provide another name for the above folder.
Set Skip Install to YES for all configurations.
Set Installation Directory of "Archive" to $(TARGET_TEMP_DIR)/UninstalledProducts.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
How to set up the project linking against the library:
Add a build configuration named "Archive" by copying the Release Configuration.
Set the Library Search Paths of "Archive" to $(BUILD_DIR)/MyLibBuildDir.
Set the User Header Search Paths to the recursive absolute path of your root of your workspace directory for all configurations.
Set Always Search User Paths of "Archive" to YES.
Set Skip_Install to NO for all configurations.
Edit its scheme, set the Build Configuration of its Archive action to "Archive."
I was not real happy with any of the other solutions that were provided, so I found another solution that I prefer. Rather than having to use relevant paths to put the /usr/local/include folder outside of the installation directory, I added a pre-action to the Archive step in my scheme. In the pre-action I provided a script that removed the usr directory prior to archiving.
rm -r "$OBJROOT/ArchiveIntermediates/MyAppName/InstallationBuildProductsLocation/usr"
This removes the usr directory before archiving so that it does not end up in the bundle and cause Xcode to think it has multiple modules.
so far I also struggled with the same problem, but did come to a solution with a minimal tradeoff:
This requires Dervied Data to be your Build Location.
I set the Public Headers Folder path to ../usr/local/include
This will ensure, that the headers will not be placed into the archive.
For the app, I set the Header Search Path to:
$(OBJROOT)/usr/local/include
$(SYMROOT)/usr/local/include
There are 2 entries necessary since the paths slightly change when building an archive and I haven't figured out how to describe it with only one variable.
The nice thing here is, that it doesn't break code sense. So except for having 2 entries rather than one, this works perfectly fine.
I'm struggling with the same problem at the moment. I didn't progress much farther than you. I can only add that in the second solution you can drag headers you need to use from the library to the app project, instead of setting ADDITIONS_PROJECT and USER_HEADER_SEARCH_PATH. This will make them visible in app project. Value of SKIP_INSTALL flag doesn't matter in this case.
Still, this solution isn't going to work for me, because I'm moving rather big project, with dozens of libraries, from Xcode 3 to Xcode 4, and it means really a lot of drag and drop to make my project build and archive correctly. Please let us know if you find any better way out of this situation.
I could use Core Plot as a static library and workspace sibling, with two build configurations:
Release:
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"
in CorePlot-CocoaTouch, Public Headers Folder Path: /usr/local/include
AdHoc (build configuration for "Archive" step in Scheme, produces a shareable .ipa):
in project, Header Search Path: "$(BUILT_PRODUCTS_DIR)"/../../public_folders/**
in CorePlot-CocoaTouch, Public Headers Folder Path: ../../public_folders
Hope it will help someone to not waste a day on this.