How to create a JFrog remote repository with a name that doesn't include the project key prefix?
I'm almost sure that it is impossible to create a repository name in a project environment, without the project key prefix.
However, please consider the following workaround:
Create a remote repository in your project named <proj>-awesome-repo.
Create a virtual repository in the default space (without project associated) named awesome-repo. Include the remote repository proj-remote-repo in the virtual repository.
Use awesome-repo as the remote repository.
If you have admin permissions you can directly create a repository without any Project key as a prefix and then you can add the created repository to that Specific Project.
If you are not an admin, then we dont have an option to create a local|remote repo without Project prefix. The only way is to associate this with any virtual repi.
Related
We use CircleCI to build our PHP app prior to deployment. One of the requirements in composer is a module stored in a private repository on Bitbucket.
Currently we store the credentials inside composer.json which is far from ideal.
The problem is that I can find no better solution for managing these credentials for repo access during the build. I'm assuming I can use an environment variable or similar.
The environment variable COMPOSER_AUTH is available to pass any number of authentication methods to composer and allows any keys or secrets to be managed outside of the repo.
In my example, to authenticate with bitbucket, the var looked like this:
export COMPOSER_AUTH='{"bitbucket-oauth": {"bitbucket.org": {"consumer-key": "xxxxxx","consumer-secret": "xxxxxx"}}}' (see: documentation)
CircleCi (and I'd assume most CI apps) has an environment variable settings page. Add the variable and value there and then you can remove the entire "bitbucket-oauth" block from composer.json.
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.
Previously I created a maven(hosted) nexus repository for my project. Named as "project-name-private"; and for version policy, I choose category "Release".
Now project members has new requirement to update the repository name as "project-name-dependency", and version policy should be expected as "mixed".
But I could not update those value from web repository settings, because those options are gray and they are not editable.
I had installed nexus repository manager 3.01-01, and I also have Admin Account/Password.
I do not want to create new repository directly because there were already artifacts had uploaded in current repository, how could I fulfill project requirement to update the existed repository? expected to get your reply. thanks.
That is currently not possible in Nexus Repository 3.x through the UI/a supported manner.
Please file an issue here and let us know your interest in that functionality: https://issues.sonatype.org/browse/NEXUS
Is it possible to have both Magnolia Public and Author under 1 instance in Jelastic? If so, how?
According to your request, I'm glad to inform you that you can easily deploy Magnolia Public and Magnolia Author under 1 instance.
As a first step, you should deploy the primary Magnolia application, you can find out that it's can be done in-one-click with help of the appropriate Magnolia CMS widget at our Marketplace
in the Portal/CMS section.
You can manage your applications and files there using Jelastic dashboard, FTP, WebDav or SSH access. In your case there is necessary to establish the SSH Access to the Tomcat instance
and perform the following:
cd /opt/tomcat/webapps/ && cp ROOT.war ROOT2.war
After the copying was finished restart the Tomcat instance.
Having reached this goal, you will obtain two separate Magnolia CMS applications.
Installed files are located at webapps directory which after the mentioned above actions will have two contexts
According to the official Magnolia documentation, it will be necessary to provide the changes in corresponding configuration files
also, it should be mentioned that the copied Magnolia application will have the same settings as an original context ROOT
so before the performing the required changes you should create another DB at your MySQL instance and then specify it for using of the second/copied application.
As a result, you will have two independent Magnolia application one of which could be set Public mode and another one to Author.
My application supports running on many dbms and it requires user to configure dbms connection setting and also provide the jdbc jar file.
Now the application is to be packaged as OSGi bundle. There will be another main jar which lanches OSGi server and starts the application as bundle.
Can you please suggest how can I package the application as bundle and let user provide the jdbc jar file.
Will it require something like the main launcher jar specifying JDBC driver classes as FRAMEWORK_SYSTEMPACKAGES property?
Thanks in advance,
Aman
There are two ways of doing this:
1) Adding the driver.jar to the classpath of the main launcher and, like you say, expose its packages via the framework by specifying that property (or actually you can use the FRAMEWORK_SYSTEMPACKAGES_EXTRA property to just specify additional packages, instead of specifying all of them).
2) Manually wrapping the driver.jar as a bundle, or doing it dynamically at runtime. For example, you could try to wrap bundles that are copied to a certain folder (similar to what Apache Felix File Install does) by using Pax URL or some other tool that can create a bundle out of an ordinary jar file for you (see http://team.ops4j.org/wiki/display/paxurl/Pax+URL).