How can I set new metadata to all my existing DAM assets(5000 assets) in my AEM production author.
AEM Environment : AEM 6.1
I would add this metadata programmatically.
Select all assets:
resourceResolver.findResources("/jcr:root/content/dam//element(*,dam:Asset)", "xpath")
and for each asset add required metadata.
Nowadays in AEM standard de-facto is groovyconsole for all tasks like migration changes/repository updates etc. If you don't want to install it on production env you still can create java class which will be executed on bundle start or you can create servlet which you can call manually.
Note: in groovyconsole you can use standard java code without any changes if you don't want to learn groovy.
If you want to set metadata based on the image, I would recommend using the CSV Asset Importer by installing the ACS AEM Tools package. Here you would need to provide the metadata for each asset in an excel.
For more information, please refer to https://adobe-consulting-services.github.io/acs-aem-tools/features/csv-asset-importer/index.html
Related
I'm trying to use the Artifactory Rest API to retrieve the latest published version of a file. The file in question is a simple zip of a bunch of YAML files used for configuration. I can upload and download these files in TeamCity using File Specs, however I can't find any reference of this functionality in the Rest API docs (or indeed, any way to do almost anything that isn't an action on a maven repository)
As you are already using the file specs, you can make use of the same file spec and use the Artifactory query language (AQL) to get the list of files. You can refer to example 2 here in this list.
You can define and use a custom Repository Layout. This way, in order to download the latest version of the file, you can use the [RELEASE] placeholder. The actual latest version will be automatically resolved by the extracted version value based on the layout.
See also:
How to create simple versioning custom layout in Artifactory
How to find the latest artifact version based on layout?
I have .NetStandard library. I'm going to use it in .NetFramework and .NetCoreApp applications.
It uses System.Configuration.ConfigurationManager package for work with config files. I need to transform these config files during my library installation.
I found 2 ways:
tools folder in nuget package with install.ps1 file in it
content folder with app.config.install.xdt file in it
Non of them is does not work - nuget doesn't run install.ps1, nuget doesn't transform App.config.
There is a code from csproj:
<ItemGroup>
<Content Include="Content\app.config.install.xdt">
<PackagePath>content</PackagePath>
</Content>
</ItemGroup>
Nuget package contains this file... So I have no idea why it doesn't work.
Is this problem related to .NetStandard? What I'm doing wrong?
Executing ps1 scripts, and XDT transforms are both features that only work with packages.config, but not PackageReference. .NET Core (and I think .NET Standard) projects only work with SDK-style projects, and SDK style projects only support PackageReference. Packages.config only works with "old-style" projects, which may also PackageReference.
The way that Microsoft's ASP.NET Core libraries deal with this difference is that they no longer read settings directly from web.config. Instead the program has to register callback functions that will modify an existing in-memory options object. For example
services.AddMyService(options =>
{
options.setting = newValue;
});
This has some advantages to your users.
They are no longer limited to storing the configuration value in the location the library author demanded. They can choose to load configuration from a database, a configuration service, an xml file, a json file, or just hard-code it in the app. But it lets each developer choose what's best for their own system.
If the user overrides a setting that the package puts in the config file, and each update of the package overrides the user's preference, the user gets annoyed that the package doesn't respect their choice to change the default.
If the user doesn't want to override a setting that the package put in the config file, and the package author doesn't want to overwrite the config file each update, then it's very difficult for the package author to change a default value.
ASP.NET Core's new model is better for everyone because the package author creates the options object and pre-populates it with default values and then call the user's delegate method allowing them to change the settings they care about. If the package author wants to change a default value, they do so in their own code, publish a new package, and users that don't change the value get the new default, and users who explicitly set the value in their code keep using the value they want to, from whatever configuration store they want.
So, the TL:DR answer is that you can't do what you asked for with PackageReference projects, but I hope my longer answer has given you ideas how you can redesign your library which gives better both the package author and package user a better experience.
I am using a working TYPO3 7.6.14 environment with many extensions. Now I want to add a composer.json file manually. I do not want to create a new project which will download the latest TYPO3 core and TYPO3 extensions. I am afraid that this could accidently overwrite some extension's PHP files.
I need a safe way to add a composer.json file which will not change the present TYPO3 PHP files automatically. I prefer to download TYPO3 and the extensions manually. Therefore I do not want to use the composer mode. I must find a way to prevent composer from overwriting my self written PHP files.
I need a composer.json file because I want to add the external TCPDF library which is on its own place on the file system and not inside of a vendor folder inside of TYPO3. And the file ext_autoload.php is not supported any more by TYPO3 7.6.
I have read the https://usetypo3.com/typo3-and-composer.html#c51 recommendations. But it only shows the way how to create a new TYPO3 project using the command line and the composer command. Is it also possible to download a composer.json file into a TYPO3 folder (which?) in order to tell the autoloader where it will find the external TCPDF library?
I have unzipped the TCPDF file under /var/www/html/TCPDF-master/tcpdf.php . I want to use TCPDF, TYPO3 and its extensions unchanged and never updated by any composer command.
Introducing Composer for not using it's features seems a bit strange to me, but yes, it's possible to define a dedicated version or commit-hash in a repository to disable updates.
However, I would recommend to make use of the tilde ~ operator to enable updates on the accordant branch, to e.g. include security updates automatically. For TYPO3 CMS this dependency would look like the following, to stay on the 7.6 branch:
"require": {
"typo3/cms": "~7.6.14"
}
Find further details on how to declare versions in the Composer documentation.
Besides that, it seems, that you're not using Composer at all for the root project. You could then create a wrapper extension for TCPDF with one of these options:
use Composer for that extension to require TCPDF and load the generated autoload file (e.g. in typo3conf/ext/tcpdf/vendor/autoload.php) in your wrapper extension
directly copy & paste TCPDF's source (which seems to be the scenario you're up to) and add the autoloading information to ext_emconf.php, which is similar to previous ext_autoload.php - find details about that in a blog post about class loading
I'm using ember-cli and I made a custom component using ember-cli syntax & naming conventions. This is a highly reusable component and I'd like to know what is the better way to put it all into a "package" so it's easy to integrate into other projects.
My component use a .js file for the Ember.Component subclass along with a .hbs file for the template and yet another couple of .js files for the necessary Ember.View subclasses. Right now, every file is in its respective folder along with the files for the rest of my project.
How can I isolate the files related to the component and package them for reuse? In Ruby on Rails I use gems for this matter, and in jQuery I used to write plugins by extending $.fn in a single file.
Take advantage of Ember CLI addon system. It's been designed for cases like this one. The process should be easy if you are familiar with Ember CLI already. As Ember CLI addon system's been reworked in the recent past and it's API was changing it's possible that older articles or guides on this topic became out of sync.
The most comprehensive and kept in sync guide on this topic is kristianmandrup's gist Converting libraries to Ember CLI addons.
There is also an Addons tutorials section on the official Ember CLI site.
I'm interested in creating a NuGet package for a documentation tool I'm writing. Ideally, I'd like the user to not have to configure my tool in anyway. In order to do this, I need to be able to read some settings from the Project's .csproj or .vbproj file to get the path of the Xml documentation file generated by the compiler. I also need to add a post-build step to the project.
I've looked through their documentation but I haven't seen any mention of being able to do this. Is this possible? If so, is there any documentation or examples of this available?
Using PowerShell script, you can access the rich VS DTE object model. This allows your package to do all kind of things that NuGet doesn't have specific features for. Look at this help topic for some info on using init.ps1 or install.ps1.