Generate static provider.json content using composer.json files

[fjmilens3]

Fixes #17 by rebuilding the provider.json for a particular vendor and project whenever an asset associated with that vendor/project pair is created, updated, or deleted.

Additional fields for autoload, require, require-dev, and suggest are included in the generated provider.json in order to correctly support autoload and dependency resolution for hosted artifacts.

Much of this implementation is essentially a stripped-down form of what we do for our Yum implementation, so hopefully keeping it running or applying the same shared lessons in the future will be made easier by this design choice. There are opportunities for improvement here as well.

Note that if this PR goes in before the outstanding group PR, then we'll need to update group merge. If the group PR goes in before this, then we should also update this to correctly account for the new fields on group merge.

[fjmilens3]

@TheBay0r, I think we're in a good place on our end to merge this down, but I'd be curious if this solves your autoload problem before I do. Most of this work is something I wanted to do later on as a technical improvement, but the main reason I did this now was to see if including this additional information solves the autoload problem.

[TheBay0r]

@fjmilens3 I'll have a look at the moment. Where some busy weeks on my end. I'll let you know about my findings! 👍

[TheBay0r]

Hey @fjmilens3 . I just saw this duplicated structure in the repository viewer, which looks to me that all packages are now /vendor/package and all the jsons are /p/vendor/package. Is this intentional?

[fjmilens3]

I just saw this duplicated structure in the repository viewer, which looks to me that all packages are now /vendor/package and all the jsons are /p/vendor/package. Is this intentional?

@TheBay0r, these changes shouldn't have changed the path in any way. These changes are focused on building the JSON content statically rather than dynamically, and including the additional fields for things like autoload as part of that process.

For what it's worth, I think they've always been that way, or at least have been for some time; I checked out commit d31c2fd16f8ebccde01c2c8cf8dae7333a3b2cf0 and downloaded a package via proxy and had the following setup:

(That said, there's still some room for improvement on my end here; before we go "live" with this it'd be nice to move all the downloads under their own subpath to avoid even the chance of a collision. On the other hand, even something that simple constitutes a "breaking change" because we conflate asset paths and asset names in our data model. So I've been holding off on those kinds of changes until we're feature-complete enough to at least declare this as alpha quality.)

[TheBay0r]

Ah yea, I saw that in the proxy before and didn't question it. Thanks.

And sorry that it took me that long, I built a couple of services using the nexus as a composer repository with this branch. I deployed these builds to our test environments. It looks very good there. Also I checked the composer.lock and it also contains all the data now.

From my point of view, your branch resolves #17

[fjmilens3]

Thanks, @TheBay0r! No worries about the delay.

As I said, you should at least consider opening up a PR to add your name to the contributors list (or let me know so that I can do so for you). Good QA counts for a lot in getting this to a releasable state.

[sonatypecla[bot]]

Thanks for the contribution! Unfortunately we can't verify if the committer(s), Frederick John Milens III fmilens@sonatype.com, signed the CLA because they have not associated their commits with their GitHub user. Please follow these instructions to associate your commits with your GitHub user. Then sign the Sonatype Contributor License Agreement and this Pull Request will be revalidated.