On Wednesday, March 12, 2014 7:44:19 PM UTC-4, garyamort wrote:
On Wednesday, March 12, 2014 7:00:20 PM UTC-4, Andrew Eddie wrote:
I think we need to deregister "joomla/joomla-framework" because it's
hiding underlying problems in our package dependencies.
I would rather it be replaced with something usable since I have no interest in listing every single joomla package manually.... I haven't kept up with the new layout in github since nothing much has been posted about what it is going to be and what the processes will be - at first glance it looks like the best option is to change the composer.json file for the joomla-framework and make it a metapackage instead.... I'll give that a try right now and post back a link.
This seems to work fairly well:
It's not a complete conversion at the moment.
Is now a composer metapackage
Deleted the vendor directory[ie the psr/log stuff]
Deleted the src directory
Modified the .gitignore file
Modified the composer.json file to include links to the Joomla packages in use by jissues.
Did not delete the other directories as I want to review them and see what makes sense in the context of a meta repository.
If you clone the repository and then run git install, you get all the joomla packages plus the psr/log package in the vendor directory.
If instead you clone my frameworkTest repository and then run composer install you will NOT get any of the files in the framework repository. You will ONLY get the individual joomla packages.
For my test repo, I had to include a repository tag to force it to use https://github.com/GarysExperiments2014/joomla-framework instead of getting the official package out of packagist. I also had to play around with minimum-stablity and such since there are not releases there.
I'll run through it some more later and see if I can get it properly configured and submit a pull request to the framework repo which would then go ahead and update the packagist.com info with a new version.
Looks like I also need to run through my composer git2Remote and git2Submodule plugins and give them pattern matching capability...manually defining a single set of overrides for Joomla-Framework was not onerous. Having to do it for each and every Joomla package would be a pain.
As an added plus, using a JoomlaFramework metapackage means that when a new Joomla Framework package is created - the meta package staging branch can add it to composer.json and when a new version is released, tag the release on the meta package in it will automatically go from dev to released.