How to use composer in Joomla 3.4

[Allon Moritz]

Hello

Since Joomla 3.4 composer is shipped with Joomla. I can't find any documentation how to use it in my extension. Can somebody shed some light into the Joomla composer integration? Thanks!!

[xillibit]

Hello,

You can foud documentation here: https://docs.joomla.org/J3.x:Using_Composer_with_Joomla and it can be helpful to read that too : https://github.com/joomla/joomla-cms/pull/3617

[Allon Moritz]

Thanks. But did you have a look on that links? They do not mention something how to use composer in an extension.

On Tue, Mar 3, 2015 at 12:58 PM, xillibit <xill...@gmail.com> wrote:

Hello,

You can foud documentation here: https://docs.joomla.org/J3.x:Using_Composer_with_Joomla and it can be helpful to read that too : https://github.com/joomla/joomla-cms/pull/3617

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

[Tom Hutchison]

Did you read 

https://docs.joomla.org/J3.x:Using_Composer_with_Joomla#Can_you_install_any_extra_libraries_via_Composer.3F

Tom

[Allon Moritz]

Yes. That's the reason why I was asking here. I hoped that there will be a way to use composer in an extension. But it looks like it can't. I wanted to be sure, before I do my own way.

[Bakual]

Currently, it's only used to maintain external libraries shipped together with the CMS.

Am Dienstag, 3. März 2015 14:02:34 UTC+1 schrieb laoneo:

Yes. That's the reason why I was asking here. I hoped that there will be a way to use composer in an extension. But it looks like it can't. I wanted to be sure, before I do my own way.

On Tue, Mar 3, 2015 at 1:56 PM, Tom Hutchison <hutc...@gmail.com> wrote:

Did you read 

https://docs.joomla.org/J3.x:Using_Composer_with_Joomla#Can_you_install_any_extra_libraries_via_Composer.3F

Tom

On Mar 3, 2015, at 7:20 AM, Allon Moritz <allon....@gmail.com> wrote:

Thanks. But did you have a look on that links? They do not mention something how to use composer in an extension.

On Tue, Mar 3, 2015 at 12:58 PM, xillibit <xill...@gmail.com> wrote:

Hello,

You can foud documentation here: https://docs.joomla.org/J3.x:Using_Composer_with_Joomla and it can be helpful to read that too : https://github.com/joomla/joomla-cms/pull/3617

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send email to joomla-dev-general@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send email to joomla-dev-general@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.
To post to this group, send email to joomla-dev-general@googlegroups.com.

[Roberto Segura]

In fact there is an issue now when trying to use it on third part extensions. Core composer defines the includeFile function ( https://github.com/joomla/joomla-cms/blob/staging/libraries/vendor/composer/ClassLoader.php#L410 ) so if you ship your extensions with another composer loader you get an already defined error. Solution is easy (but a bit annoying) wrap includeFile in your ClassLoader with:

if (!function_exists('Composer\Autoload\includeFile'))
{
}

I think it's more a composer issue because it will fail also with 2 extensions using composer.

[Allon Moritz]

A first test on my side didn't produce any issues with my own composer auto loader on Joomla 3.4.

So, just for the record. Nothing changed for the extensions which do update their libraries trough composer in Joomla 3.4.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send email to joomla-de...@googlegroups.com.

[Johan Janssens]

Hi all,

The information on https://docs.joomla.org/J3.x:Using_Composer_with_Joomla is not 100% correct and steps provided should be handled with care to not run into issues :

Can you install any extra libraries via Composer ?

Not at the moment in Joomla! 3.4. In the longer term it is the CMS's aim that you can download extra packages. To emphasize this, we will not yet be releasing the composer.json file within the main Joomla! download.

Not 100% correct. The answer is yes, you can but you need to take care what steps you take.

Joomla is distributing the composer.json file through Github but not through the downloadable packages. Using composer with the downloadable packages will get you into trouble as Joomla uses a none default location for it's vendor folder /libraries/vendor vs /vendor (default). 

If you would use compooser without the Joomla composer.json file in place you will not be able to update the Joomla dependencies yourself. Composer will just halt at that point and tell you to do an init or put a composer file in place.

Be careful here, if you then init composer and put your own file in place without using the Joomla composer.json file. Compooser will initialise itself in the default /vendor folder. This will not work, as Joomla cannot load your dependencies from the folder.  

Side note 

Using a custom vendor folder location is not recommended and Joomla would be better to use the default /vendor the going of path by using it's own location. 

To ensure you have the composer.json in place  you clone the repo from Github or download the source code (click on source code zip) through Git. Then you can update (as the documentation suggests) or install additional libraries using composer. If you downloaded the package you could just copy the composer.json file in place from Github to make it work.

Side note 

The compooser.json should be distributed by Joomla at all times. If Joomla requires specific libraries to use specific versions the composer.json file can specify this. This is the whole idea behind composer, if you specify a specific version you locked it down. (See Composer documentation.)

 

@Laoneo : You can perfectly use Composer in both Joomla  3.4 (and even in 3.3) to install external libraries. You can also use it to install Joomla extensions using our the Joomla composer installer plugin we developed. Instructions on how to do this can be found on our developer site : http://developer.joomlatools.com/tools/composer/introduction.html 

@Robert : The issue you pointed out can be easily resolved by changing the Composer integration in Joomla slightly. At Nooku we are working on a fix. More details about the issue and fix : https://groups.google.com/forum/#!topic/nooku-framework/GRb40gB9ZJY

Cheers,

Johan

On Wednesday, March 4, 2015 at 4:47:38 PM UTC+1, laoneo wrote:

A first test on my side didn't produce any issues with my own composer auto loader on Joomla 3.4.

So, just for the record. Nothing changed for the extensions which do update their libraries trough composer in Joomla 3.4.

On Wed, Mar 4, 2015 at 2:52 AM, Roberto Segura <rob...@phproberto.com> wrote:

In fact there is an issue now when trying to use it on third part extensions. Core composer defines the includeFile function ( https://github.com/joomla/joomla-cms/blob/staging/libraries/vendor/composer/ClassLoader.php#L410 ) so if you ship your extensions with another composer loader you get an already defined error. Solution is easy (but a bit annoying) wrap includeFile in your ClassLoader with:

if (!function_exists('Composer\Autoload\includeFile'))
{
}

I think it's more a composer issue because it will fail also with 2 extensions using composer.

El martes, 3 de marzo de 2015, 20:51:05 (UTC+1), Bakual escribió:

Currently, it's only used to maintain external libraries shipped together with the CMS.

Am Dienstag, 3. März 2015 14:02:34 UTC+1 schrieb laoneo:

Yes. That's the reason why I was asking here. I hoped that there will be a way to use composer in an extension. But it looks like it can't. I wanted to be sure, before I do my own way.

On Tue, Mar 3, 2015 at 1:56 PM, Tom Hutchison <hutc...@gmail.com> wrote:

Did you read 

https://docs.joomla.org/J3.x:Using_Composer_with_Joomla#Can_you_install_any_extra_libraries_via_Composer.3F

Tom

On Mar 3, 2015, at 7:20 AM, Allon Moritz <allon....@gmail.com> wrote:

Thanks. But did you have a look on that links? They do not mention something how to use composer in an extension.

On Tue, Mar 3, 2015 at 12:58 PM, xillibit <xill...@gmail.com> wrote:

Hello,

You can foud documentation here: https://docs.joomla.org/J3.x:Using_Composer_with_Joomla and it can be helpful to read that too : https://github.com/joomla/joomla-cms/pull/3617

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.

To post to this group, send email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.

To post to this group, send email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsubscribe@googlegroups.com.

To post to this group, send email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[George Wilson]

On Wednesday, March 4, 2015 at 8:35:25 PM UTC, Johan Janssens wrote:

Hi all,

The information on https://docs.joomla.org/J3.x:Using_Composer_with_Joomla is not 100% correct and steps provided should be handled with care to not run into issues :

Can you install any extra libraries via Composer ?

Not at the moment in Joomla! 3.4. In the longer term it is the CMS's aim that you can download extra packages. To emphasize this, we will not yet be releasing the composer.json file within the main Joomla! download.

Not 100% correct. The answer is yes, you can but you need to take care what steps you take.

Joomla is distributing the composer.json file through Github but not through the downloadable packages. Using composer with the downloadable packages will get you into trouble as Joomla uses a none default location for it's vendor folder /libraries/vendor vs /vendor (default).

So we aren't distributing it in the public packages then...

 

 If you would use compooser without the Joomla composer.json file in place you will not be able to update the Joomla dependencies yourself. Composer will just halt at that point and tell you to do an init or put a composer file in place.

And nor should anyone ever be looking to update the Joomla dependencies. It's the equivalent of making core hacks.

 

Be careful here, if you then init composer and put your own file in place without using the Joomla composer.json file. Compooser will initialise itself in the default /vendor folder. This will not work, as Joomla cannot load your dependencies from the folder.  

Side note 

Using a custom vendor folder location is not recommended and Joomla would be better to use the default /vendor the going of path by using it's own location.

There's nothing wrong with it. It's a fully documented composer feature https://getcomposer.org/doc/04-schema.md#config . Joomla has always kept it's libraries in the libraries folder and we intend to keep with that tradition (FWIW Drupal is also following a similar process by putting there things in https://github.com/drupal/drupal/tree/8.0.x/core/vendor) 

Side note 

The compooser.json should be distributed by Joomla at all times. If Joomla requires specific libraries to use specific versions the composer.json file can specify this. This is the whole idea behind composer, if you specify a specific version you locked it down. (See Composer documentation.)

As we are actively discouraging people (as per the documentation) from doing this there is absolutely no need for people to have the composer.json. If you want to hack around it feel free to. But there is no reason for us to make it easy for you to hack around it (and it is a hack)

Kind Regards,

George

[Michael Babker]

I'd highly suggest taking a look at Druapl's Composer integration.  And FWIW, the Drupal 8 Beta 7 package includes a composer.json file.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[George Wilson]

Apologies. Reading over it this came out harsher than it was intended. But the point is for extensions the official recommendation is deal with libraries as you did before (install a custom library with your extension where you can manage your own dependencies).

Johan your solution for the loading of the composer classes looked pretty good to me. I'd love to see that improved on in core.

Kind Regards,

George

[Johan Janssens]

Hi George,

Thanks for the reply. Pretty disappointing. About the points you made :

1. Using a custom vendor folder

This is indeed a fully documented feature, it's not the default however and it's a very bad idea. It's not because you can you should.

The vendor directory is a black box. The public API is vendor/autoload.php : https://igor.io/2013/09/04/composer-vendor-directory.html

More specifically in Joomla's case. 

The problem with the custom vendor folder (due to the absence of the composer.json file in public packages) is that when you now install a dependency composer will not use  /libraries/vendor (as this information is part of the composer.json config) but revert to using the default /vendor. Because of this composer will set itself up twice. Once in /libraries/vendor (hardcoded by Joomla) and once in /vendor. Bad bad!

2. Discouraging updating dependencies

The whole premise of Composer is that it allows you to do application wide dependency management. If you want to discourage developers from doing that then don't use Composer.

Joomla 3.4 is breaking about every rule in the Composer playbook :

1. Removal of the composer.json file

2. Custom vendor location

3. Committing of the dependencies in the vendor folder  (link)

4. Introducing implementation kludges that require workarounds (link)

5. Telling developers not to update dependencies

6. Committing Composer generated files  (autoload.php and /vendor/composer)

Joomla 3.4 puts up a really good example of how not to use composer and in that process makes the lives of all us developers who use it in Joomla a lot harder. You even go as far as discouraging us to use it.

Pretty disappointed George with your final comment : 

"There is absolutely no need for people to have the composer.json. If you want to hack around it feel free to. But there is no reason for us to make it easy for you to hack around it (and it is a hack)"

Composer is one of the most vital tools we as a community has created in the past years. It's the glue that binds us all together. And you are telling me as there is no reason for me to use it in Joomla and if I do you consider that a 'hack' ? Really ?

You are showing a clear misunderstanding what Composer is all about. If you want to commit dependencies in a custom folder and not allow them to be updated then don't use Composer. 

What Joomla 3.4 should have done is integrate a PSR-1/4 compat autoloader, and keep all libraries in /libraries. Update them manually when needed and leave Composer to those people who want to use it install additional dependencies in their custom projects. Yes some still use Joomla for custom projects.

Using a tool because it's cool and then breaking because you can it is hurting both the PHP ecosystem and further weakening Joomla's reputation among developers. #fail

Johan

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! General Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-general/hYZz5JI8ZFA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to joomla-dev-gene...@googlegroups.com.

[Michael Babker]

Committing the vendor directory I think is a compromise we'll have to make with the CMS.  Otherwise, that's an extra layer of complexity in getting contributors working with the git repo (they have to have Composer installed and functioning on their systems).  At least in the current form one can still grab a snapshot of the git repo and have a ready-to-go package (granted with extra things like the test suites and build scripts).

As for the custom location, remember that every top level directory is something that's blocked from being used in URLs.  "vendor" might be something that you'd be more prone to see in URLs compared to "components".

FWIW I actually had the Composer code originally in the CMS root, I had to be convinced to move it and I'm still not sure I like it, but alas that was the consensus.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Johan Janssens]

Michael,

Committing in /vendor is bad and should't be compromised on. The problem with contributor complexity is not a valid argument to me. Comooser is super easy to install, and if you want to make this even easier use our Joomla Vagrant Box, it has it included, the next version will even automatically run a Composer update for you when you install a site into it. 

If /vendor in root url is a potentially issue is a valid argument. It doesn't matter though, if you don't want to allow external dependency management (which per documentation yo don't) you don't need Composer.  

Johan

[Bakual]

Composer is a dev tool. Not a production tool.
Having the vendor folder committed to the repo is actually required if you want to have proper change management of your final product. Otherwise the only change you see in your log is the composer.json change. The changes of the ext library would have to be checked in their repo manuälly.
There is at least nothing wrong with it. It's just different way to use it, and the one that makes most sense to a CMS like we have.

Having testers be required to use composer is out of topic. It may be easy for you, but certainly isn't for everyone. Also vagrant and all those other geeky stuff isn't something for everyone. Basically as soon as you require someone to use a CLI command, you scare away most of our testers. Even running our generatecss.php script is to much requested most of the time.

[Michael Babker]

Beyond the CMS world, Composer is very much a tool used in production environments.  I have several projects, including the issue tracker, which are sync'ed via git and use composer to install dependencies at the live server.

As for ignoring the vendor folder, I prefer it.  If I need to check code changes in dependencies, I know I need to check their changelogs or repos.  I use the composer.lock file to keep projects at the same set of dependencies.  I also realize that that isn't as practical in our environment if we want to keep a lower barrier to entry.  If we wanted to keep contributors only to people who could use command line, we could probably stop having compiled CSS in the repo too and only assemble that at packaging time (if you can use Composer, you can use Grunt or run our generator script logic).

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

To post to this group, send an email to joomla-de...@googlegroups.com.

Visit this group at http://groups.google.com/group/joomla-dev-general.
For more options, visit https://groups.google.com/d/optout.

--
- Michael

Please pardon any errors, this message was sent from my iPhone.

[Bakual]

Imho, one should never use it directly on a productive server.
One should use it on a build server, and deploy from that server to production after tests have passed.

[Oli Griffiths]

May I ask why you're using composer in Joomla at all?

It seems to be that composer is used for dependency management of core joomla packages. If you're committing the vendor directory then why bother using composer at all? Why not manually install the packages as Joomla has done for years in the /library folder?

If you're using composer for dependency management as a simpler way to install core dependencies, and have those dependencies under source control, why bother? What's the point? Why not just manually include those relevant packages? That way users don't need to run composer install in order to get set up, and the rest of us can use composer as it's supposed to be used.

[Bakual]

Then intention was to eventually have a possibility for extensions to use composer. The current implementation is meant as a starting point where we can build on.
Feel free to propose code to improve it, or change it. It's not written in stone. The only things I think are a requirement are:

• Our testers and users don't need to use CLI commands to install the CMS
• No top level "vendor" folder, as it could very likely break sites
• Our core libraries have to be locked down in version.

But having the core libraries in our vendor folder isn't a game breaker anyway. Of course we could include them manually like we always did. But why should we? It's simpler to update them using composer.

Our users don't need to run composer in our current implementation, but we can do it in our development process and update the packages and test them.

I don't understand what stops you from using it yourself. As far as I understood laoneo it still works as before for extensions who already used it.

[Mathew Lenning]

Has anyone here ever asked themselves why Joomla insists on implementing technologies that could possibly encourage greater adoption in such a way that it actually discourages adoption?

If someone has a choice of two CMS with composer, one that implements it like every other project or one that implements it unlike any other project, which one do you think is going to be the obvious choice?

If we don't intend to follow industry standard practices for industry standard solutions why use them at all?

We don't want to reinvent the wheel, but requiring specilized lug nuts to attach it to the vehicle is OK? Seriously?

[Anibal]

Hi,

In my opinion, Composer in Joomla sounds great and slides are amazing.

Down the road, the current implementation is not so exciting. The only use case is in the core ... Future revisions can freely changed it with no BC hell.

Regards,
Anibal

[George Wilson]

The vendor directory is a black box. The public API is vendor/autoload.php : https://igor.io/2013/09/04/composer-vendor-directory.html

Your link says one reason is that "Legacy: You have some legacy project that heavily relies on the location of files. You cannot break BC". To which his solution is "let it die". We're not going to let Joomla die. But until 4.x I don't think we plan in any way to let Joomla die. But unfortunately until 4.x we do rely heavily on the location of files.

 

2. Discouraging updating dependencies

The whole premise of Composer is that it allows you to do application wide dependency management. If you want to discourage developers from doing that then don't use Composer.

The premise is also that Joomla Extensions are installed via composer (something interesting to do but hard in practice). When that doesn't happen it becomes horrendously hard to integrate your extensions with composer.

I have an extension (unfortunately one I've build privately at work so can't share). But it involves pulling in some 3rd party libraries with composer (which I am installing into Joomla as a library with my extension) and I've had no issues when updating to Joomla 3.4 so I don't know exactly how you're hitting this bug anyhow.

As for committing the vendor folder I think your severely overestimate the level some people come to Joomla with. Certainly when I started contributing to Joomla there was no way I'd have been happy using command line based applications.

Either way my point is that sure there are places we can improve on. But the way we've implemented composer as a first base in my opinion is fine.

Kind Regards,

George

[Ben Huebscher]

Now that Composer support has been screwed up with this hack, how are actual developers supposed to manage third-party dependencies? I understand the necessity to allow non-developers to install/upgrade third-party extensions through the web interface, but real development has to be done in a way where third-party dependencies can be managed in a source controllable way. Composer is recommended way to do this in PHP (by committing both the composer.json and composer.lock files to the repository).

I've been holding off on taking on a project involving migrating a site from Joomla 2.x to 3.x because I thought Joomla 3.4 was supposed to finally bring native Composer support. Instead, it's now harder to use Composer with Joomla. Is there a plan to fix this in 3.5? If there is not, I'm going to have to tell my client that my recommendation is to abandon Joomla entirely. The ability to use a package management is a must-have in modern development.  

[Michael Babker]

There is nothing blocking you from using Composer with your project's dependencies.  The way I've approached it with my own projects thus far is to include the vendor directory within my extension's directories and have a composer.json file in my extension's repository and for distribution package a stripped version of it (removing automated tests, docs, and other non-production code) with the installable package.

Joomla commits the composer.json/lock files to the repo but they are stripped at packaging (see https://github.com/joomla/joomla-cms/blob/3.4.4/build/build.php#L115); the resources are there.

The current structure of the core Joomla Composer installation doesn't allow users to include their dependencies in the core vendor folder and be included through the autoloader that is generated running a `composer install --no-dev` on the CMS root when working within git.  It is still a work in progress to address this but frankly it isn't the simplest thing to do.  IMO, Composer isn't a (yet) proven dependency manager for non-Packagist based distributed plug-and-play platforms like Joomla or Drupal (who have 2-3-year-open issues trying to address Composer integration in their platform).

So, your options basically come down to having an additional Composer installation for the additional dependencies within your extensions or run Joomla from the git repo with a modified version of the Composer .json/.lock files and vendor folder and reconcile that with each release.  Not the best answer, I know, but that's the only answer at this very specific minute.

--

You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Johan Janssens]

Hello Ben,

I feel your pain. The composer integration is pretty messed up in Joomla 3.4. If it will be fixed still fails to be seen. So far nothing on the roadmap for 3.5 or 3.6 in that direction. 

Instead of waiting for this we have fixed this problem in our Joomlatools Platform. We refactored the composer integration to work the way it should work using the composer best practices and default and additionally moved core components into separate repos to lighten the core.

The platform is a distro of Joomla 3.3.6 (1.1 version will be based on 3.4.x), with additional changes to cater to the 12 factor methodology (http://12factor.net/). It's 2 times faster and 75% lighter then a stock Joomla install.

More info :

- https://github.com/joomlatools/joomla-platform

- www.slideshare.net/mobile/joomlatools/joomlatools-platform

Changelog for 1.0 : https://github.com/joomlatools/joomla-platform/releases/tag/v1.0.0

If you have more questions about this feel free to jump on our chat or mailing list. 

Happy coding!

Johan

[Michael Babker]

On Thu, Nov 26, 2015 at 8:14 PM, Johan Janssens <jjan...@gmail.com> wrote:

Hello Ben,

I feel your pain. The composer integration is pretty messed up in Joomla 3.4. If it will be fixed still fails to be seen. So far nothing on the roadmap for 3.5 or 3.6 in that direction.

The Composer integration is only "pretty messed up" if you are of the belief everything has to be done the One Right Way™.  Joomla as a CMS has mitigating circumstances that warrant breaking the One Right Way™ for the better of the project's development.  Most developers that I've talked to about the subject agree that it would be nice to restructure the application following best practices however also feel that doing so alienates many contributors to Joomla today and feel making a move to follow best practices has greater risk than reward.  It seems though the Joomla 4 Working Group agrees with your assessment and has decided to remove the vendor folder from version control.

Instead of waiting for this we have fixed this problem in our Joomlatools Platform. We refactored the composer integration to work the way it should work using the composer best practices and default and additionally moved core components into separate repos to lighten the core.

Indeed the way your platform is structured it does fix all of the developer concerns with regards to the Composer integration.  Even going so far as to having written an integration for Composer itself which allows Joomla extensions to be installed via Composer.  Speaking strictly as a developer and system administrator right now, this is great and is in line with how projects I build with Joomla's Framework, Symfony, or just a Frankenstein combination of random packages assembled into an application are managed.  If I were building client sites using Joomla and were looking to lock down the application stack rather strictly and could accept the core API being a little behind the base Joomla application I would seriously consider using it.  However, I could not in good faith recommend that this be the future of Joomla as a full stack application, in part because of the end user functionality that has been removed.  Those pieces help to enable folks who aren't able to run a git clone or feel comfortable working in a CLI environment or write Joomla extensions be able to quickly manage and customize various aspects of their site.

I'm basically left with the feeling that using Composer to manage Joomla's dependencies was the biggest mistake ever.  In part because of all the screaming about not doing things the One Right Way™ and in part because of how few folks are truly understanding of the workflow to run a `composer update` on any package.  It'd seriously be easier to just go back to days of olden and constantly hack third party code to fit the Joomla Way™ and be done with it. 

[piotr_cz]

Woww, this is how the Joomla structure should look like in 2015.

Thanks for sharing, kudos to Joomlatools team.

[Anibal]

 Hi, 

At this time, I'm working in the iteration of my extensions. Composer is widely adopted and most libraries to connect with Facebook, Telegram, Google, etc are already distributed via Composer. Dependencies are pulled from there and PHP 5.5.9 seems to be the new standard.

Back to this old topic, I'm looking for a way to adopt the new libraries. The current Joomla implementation works perfectly fine and libraries can be loaded via Composer in an extension context .... however the issue about multiple libraries versions is still present. For instance, if Joomla loads paragonie/random_compat and an extension loads paragonie/random_compat v2.0.2, then we can't be sure of the outcome. We can expect that more extension developers will adopt more libraries. So, the issue will only worsen with time. I have confirmed that other extensions are simply packaging the standard libraries that they require.

As a way to solve the namespace/class collisions, FOF30 implemented Pimple container adding a new level (managed by FoF autoloader): namespace FOF30\Pimple;

FOF solution works Ok for a specific and limited case. But, if an extension requires more than 1 library (let's say 10 dependencies), a general solution must be implemented.

I've been testing a similar solution to add a new level in all libraries packaged inside the extension and "fixing" the local declaration routine. The process is like this:

1. An extension project, with a vendor folder inside. Vendor folder has classes like namespace MyExtension\GuzzleHttp;

2. A libraries project, where the standard libraries are managed (e.g. namespace GuzzleHttp;)

3. A packaging script that replaces namespaces (there are several cases to take into account) ... and modifies the local composer autoload to find the libraries with the new names.

In my preliminary tests, it is working fine and it has no impact in the rest of libraries. So, it would be great if we can standardize this practice for all extensions. It is not a perfect solution, but that's the best we can do to improve the current Composer implementation.

Let me know if you have a better way to implement Composer libraries or if there is something missing in this prototype to improve a Composer implementation.

PD: Joomla libraries/vendor would remain the global implementation with the standard namespace.

Regards,

[Johan Janssens]

Hi Anibal,

Composer is a application dependency manager, not a library manager. If you are including libraries in your own extensions and then registering those with the global composer auto-loader manually you are doing it wrong and setting yourself up for trouble. This is not how composer should be used. Instead package the library with your extension and provide your own PSR loader, load the library when needed.

If you are creating extensions and installing those using our Joomlatools composer installer you should take care to use proper version numbers for the libraries so composer can handle conflicts for you during composer install or update. Composer is pretty good at handling these and making you aware of any potential conflicts. See also : http://stackoverflow.com/questions/21052831/how-to-solve-two-packages-requirements-conflicts-when-running-composer-install

Hope that helps.

Johan

[Anibal]

Hi Johan,

I agree that loading libraries manually (modified to have an additional namespace) with composer is not a standard use case. Composer can change at any time and vendor/composer/autoload* files should not be modified to keep them as they were generated. So, a custom auto-loader is always an option.

Thank you for your feedback,