[3.4] Composer Integration

[mbabker]

Part of the vision for 3.4 is integrating Composer into the CMS. This pull request as of this time represents a working solution for this. Changes with this pull request:

• Composer installed code is under libraries/vendor
• Third party code which we have manually added that is installable via Composer is handled as such (Symfony YAML component, the password_compat library, PHPMailer, and lessc)
• Framework code we have manually imported is moved into the Composer installation
• The Framework's DI package is updated to 1.2 (we're shipping 1.0 as of 3.3)
• The Platform's Input package is replaced with Joomla\Input from the Framework with class mapping for B/C (same as what was done for the Registry package)
• The build script is modified to only package production files from the Composer installed packages
• JApplicationBase now extends Joomla\Application\AbstractApplication and now duplicated code or class variables in that class and child objects are cleaned up

TODO:

• Verify the build script is working completely as intended for all package types
• Determine if unused Framework packages (brought in because of dependencies within the Framework code) should be packaged with releases; if so then we should look at perhaps using it and removing the Platform equivalent otherwise we should ensure the build script excludes those files

[wilsonge]

OK so I've PR'd against the Framework Application branch to remove the event dependency like we discussed a while ago but never did - so that should remove that from the PR. Also PR'd input to update copyrights there to 2014.

Finally I there have been some minor changes but I think we can map JArrayHelper - but there have been some minor changes so we'd need to make sure there are no b/c breaks there - I only glanced over.

[mbabker]

I looked at it. Typehinting, protected methods being renamed and declared private; can't happen.

[wilsonge]

@test I've been building a new website template on this branch and everything seems to be good. no issues in things like akeeba backup or some of no numbers extensions + tested the majority of core extensions without issues.

I reckon we're probably good to merge this.

[Fedik]

have question,
as I understand currently this only for build the CMS, or?
how it will be for extension developers, to install additional libraries? or this not planned currently?

[johanjanssens]

@Fedik For extension developer who wish to install extensions in Joomla you can check out our Joomlatools Composer installer plugin. The plugin is capable of installing any type of extension into Joomla.

Github repo can be found here https://github.com/joomlatools/joomla-composer and developer docs are here : http://developer.joomlatools.com/tools/composer/introduction.html

[mbabker]

@Fedik - At the moment, this is only affecting the main CMS build. The intent is to further the integration to allow developers to use it, but right now that isn't coded.

All - Updated test packages are posted to http://developer.joomla.org/PR-packages/3617/ in sync with commit c9d22b9

[pete-rossetti]

Installed the update package on the latest staging version. Initially got a white screen on update then after a couple of refreshes it confirmed install successful.
Update from web button does not work, in extension manager
Tested 3.4.0dev by installing JEvents, Chronoforms, Phocodownlods and Virtumart 2.9 successfully

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3617.

[sandstorm871]

I have tested a clean install of 3.3.6 staging on MAMP server using PHP5.5.10
Then used the 3.4dev update package & all seemed to update OK.
Installed a handful of components including JCE, Akeeba admin tools & backup, Sh404 & Virtuemart 2.9.9 ;) all seems to work OK.
I did notice that "Install from web" button doesn't work


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3617.

[smehrbrodt]

Is there a reason you add the libraries/vendor folder to git?
Wouldn't it make more sense to exclude it from git and just include them in the release builds?
(And add a note for those who check out from git to do a composer install after checkout?

That's how Composer is usually used AFAIK.

[Bakual]

Wouldn't it make more sense to exclude it from git and just include them in the release builds?
(And add a note for those who check out from git to do a composer install after checkout?

It's one way you could do it, but it makes it harder for people to test using a Git repo as they need composer installed and need a bit of knowledge about how to use it.
It also makes the build process more complex and adds risks that it fails due to server not reachable or similar. Travis also would always have to do the composer stuff before running unit tests.

I don't see any drawback having the vendor folder in the repo under version control.

[mbabker]

@Bakual covers some of the logic well. The primary thought at this point is that there is a much higher level of skill needed to be able to use the CMS from the source repo if we required everyone to be able to download and install Composer locally. The build scripts or Travis issues aren't as big of points IMO; everyone is dealing with that today (including myself in other projects) and I'd say Composer's caching works well unless you're installing never-before-used code on a platform (or using a platform which doesn't cache such as Travis). FWIW, Drupal 8 also includes their core/vendor folder in version control.

[mbabker]

Updated test packages are posted to http://developer.joomla.org/PR-packages/3617/ in sync with commit 26f09fa

[haydenyoung]

@test

Successful test of core installation and update from 3.3.x.
Successful test install and configure Kunena
Successful test install and configure JSpace (installer installs plugins + modules)
Successful test install of custom template

Also tested installing 3rd libs via composer. It deleted contents of libraries/vendor but installed successfully.

Installed Aws S3 via custom composer.json to libraries/vendor. Was able to register namespaces and use libs:

JLoader::registerNamespace('Aws', JPATH_LIBRARIES.'/vendor/aws/aws-sdk-php/src/');
JLoader::registerNamespace('Guzzle', JPATH_LIBRARIES.'/vendor/guzzle/guzzle/src/');
JLoader::registerNamespace('Symfony', JPATH_LIBRARIES.'/vendor/symfony/event-dispatcher/');

use Aws\S3\S3Client;
use Aws\S3\Exception\S3Exception;

$s3 = S3Client::factory();
try {
$s3->putObject(array(
'Bucket' => 'my-bucket',
'Key' => 'my-object',
'ACL' => 'public-read',
));
} catch (S3Exception $e) {
echo $e->getMessage();
}

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/3617.

[Bakual]

Based on the various tests I'm marking this RTC. Thanks all! This finally clears the way for Joomla! 3.4 Beta 👍

[b2z]

WoW! Thanks a lot to all who was working hard on it! 👍

[Bakual]

Tried to merge using a diff but had to revert since it messed up the file moving. Will try again later on :)

[Bakual]

Now merged for real 😄