I am using artifactory and have no issues with the npm solution. However, I have set up composer using the "Set Me Up" instructions, i.e. installed the ~/.composer/config.json & ~/.composer/auth.json files. I now get the following error when I try to perform a composer install:
$ dcomp install
Loading composer repositories with package information
[Composer\Downloader\TransportException]
The "https://myartifactory.jfrog.io/artifactory/api/composer/php-local/packages.json" file could not be downloaded (HTTP/1.1 404 Not Found)
install [--prefer-source] [--prefer-dist] ...
The user I have configured in auth.json is an admin user, and I've pushed a single package into the Artifactory. Additionally, I noticed the url contains plural packages.json as opposed to singular package.json, so I am assuming this is an issue with the artifactory configuration itself and not the package I've uploaded.
For Artifactory to index composer packages successfully you also need to make sure that each package has version specified.
There are 3 ways to achieve that:
Include the version attribute in the package composer.json file
Set a composer.version property on the package itself.
Use the version field when deploying it via the UI.
You can easily test it inside the UI by clicking on the archive you just uploaded, then go to the properties tab and add a property for example:
composer.version with value for example 1.0.0.
The issue in my case was as a couple commenters observed: the index wasn't being generated.
For me, the fix was a matter of using a .zip compressed file to upload composer packages instead of a .tar.gz. I can't tell you why a tarball won't work, especially considering Artifactory's documentation explicitly mentions tar.gz, but it would appear .zip is the way to go.
When you first create a PHP composer repository in Artifactory it will not have the repository index yet (package.json file). The index will be created only after you deploy your first package.
It is possible that Artifactory was unable to read the package metadata for the package you deployed. In such a case, assuming this is the only package in the repository, the index will not be calculated.
In order to verify this is the case:
Browse the php-local repository in the Artifactory UI
Check for the presence of a .composer/packages.json file (relative to the repository root). If it does not exist, it is an indication that Artifactory was unable to calculate the repository index
Select the package you deployed, and switch to the Composer Info tab
Check that you can see the correct package version. If you see "No version found" - there was an issue with getting the version (probably because it is not included in the composer.json file)
Look for an error similar to the following in the artifactory log file:
Failed to persist package metadata for 'php-local/my-package.zip'.
Unable to read the package version from the extracted composer.json
file
If this is the case, you can solve the issue by:
Add a property named composer.version to your composer package and set its value to be the correct package version. You can do it by selecting the package file from the UI, switching to the Properties tab and adding a new property
If this done correctly you should be able to see the correct version in the Composer Info tab and that the packages.json file is being generated
If all of this does not help and the packages.json file is still not generated, there is probably another error which prevents Artifactory from generating it.
Try re-generating the repository index by:
Going to the root of the repository in the Artifactory UI
Right click the root of the repository and choose "Recalculate Index"
The index should be generated in the background
If the index is still not generated search the artifactory log file for any relevant error messages
Finally, one more option to try is deploying a different composer package and seeing if it behaves the same.
I have seen an Include / Exclude Pattern on the Jfrog repository that does not match the <vendor>/<package> naming standard cause this issue. We were able to upload artifacts but they were excluded metadata endpoint.
The following endpoint returned a 404 response code for every package until the Include / Exclude Pattern was fixed.
https://<org>.jfrog.io/artifactory/api/composer/<repo>/p2/<vendor>/<package>.json
Related
I have artifacts in JFrog.
Example:
https://test.com/artifactory/users/data-config/1.0.0/user.json
https://test.com/artifactory/users/data-config/1.0.1/user.json
https://test.com/artifactory/users/data-config/2.0.0/user.json
Is there a way I can download the latest version using curl? Like in this case it will be
https://test.com/artifactory/users/data-config/2.0.0/user.json
Considering your comment that the files are not maven based, I assume it is deployed to a generic repository and irrespective of the file type, the only way to resolve the file via direct cURL is using the following command.
curl -u<USERNAME>:<PASSWORD> -O "http://<HOSTNAME>:<PORT>/artifactory/generic-repository/<TARGET_FILE_PATH>"
So, the target path name should be given completely when it is being resolved via direct download (API). i.e., The complete target file name manually.
However, for other package types such as a maven release or a snapshot, the available options are described here.
What are a few other additional options available?
Artifact Latest Version Search Based on Layout
, Artifact Latest Version Search Based on Properties
Issue : I am following the URL. https://docs.fedoraproject.org/en-US/java-packaging-howto/packaging_maven_project/ to create a spec file for the rpm package.
In the website "BuildRequires: maven-local" is mentioned in the spec file.
but when I tried to search 'maven-local' using yum search maven-local command, I could not find anything and as I was not able to install the component, I'm getting an error when I am trying to do rpmbuild.
Note: I even installed maven separately in my system but it did not help me to fix the issue.
I recently added a new package and directory to my Go project, and now when I try to build it, I get errors about a password error on Gitlab.
I am not importing a new remote package, I am simply adding a new directory underneath my already declared module path. For instance, my go.mod has gitlab.com/example/api and the package I added is gitlab.com/example/api/postgres.
I am not actually hosting on gitlab, I just needed something to name the project as I worked on it. Clearly it won't find it on gitlab, but it is available locally. Why is go-get trying to download a package/path that is available locally?
Why is it only happening for this new package, and not for all of the existing package under this path?
Golang 1.14
You have to add replace above the require block in your go.mod to work with local package. For example:
replace gitlab.com/example => /Users/abc/projects/gitlab.com/example
Ref: https://github.com/golang/go/wiki/Modules
Say you are using Go 1.13 and set up a project initialized for Go Modules.
$ mkdir my-project
$ cd my-project
$ git mod init github.com/bmuschko/my-project
Instead of using the default Google proxy to download dependencies, you set GoCenter or a different proxy.
$ export GOPROXY=https://gocenter.io
Once you download dependencies, it doesn't seem that Go keeps track of the originating proxy. In the end, there's no way to know or verify that a dependency came from the Google proxy, a custom proxy or directly from the source code repository. In theory, the checksums could be different depending on the originating proxy if you switch between them even if you pull the same version.
$ go get github.com/spf13/cobra
Does Go store this information somewhere in the cache? I couldn't find this information. Any advice would be appreciated.
The originating proxy should not matter and is not recorded: if you have downloaded the module from anywhere, then the bytes in your module cache should match the checksum found in either your go.sum file or the global checksum database.
(The go command fetches checksums for any new module dependencies from the database before downloading the module or adding the checksum to your go.sum file.)
I am trying to create a module based on this example Oxid 6 module
https://github.com/linslin/oxid6-example-module
I have changed and cloned it to
https://github.com/v3ritas1989/gg_oxid6-example-module
as well as into my local module folder
..modules/compname/modulename
So for the beginning I want to change the modulename, submodul folder name and the namespace given
modules/companyname/modulename
Path Example:
modules/linslin/oxid6-example-module
However if I try to install my module
via composer
composer require compname/gg_oxid6-example-module:dev-master
(for local folder)
composer require v3ritas1989/gg_oxid6-example-module:dev-master
(for git)
I get ERROR:
[InvalidArgumentException] Could not find a matching version of
package compname/gg_oxid6-example-module. Check the package
spelling, your version constraint and that the package is available in
a stability which match es your minimum-stability (stable).
What I dont understand is why
composer require linslin/oxid6-example-module:dev-master
is working even so I deleted the local folder linslin
I guess it is pulling it from github?
but why then does this not work with my changed module and my github repo?
I made only search replace
modulename
compname
namespacename
Question:
I am assuming composer just does not find my repo or local.. so
How do I do composer require in a way that it only checks my local
folder?
Why does it also not find it in my github?
you need to register repository in your main composer.json file as described here:
https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository
or register your package in https://packagist.org/ so it would be automatically detected.
There are also other ways of registering repositories, for example define it as local repository: https://getcomposer.org/doc/05-repositories.md#path