Split to multiple bundles about platform HOT 20 CLOSED

OroPlatform looks like a new distribution of symfony.. which is great- because we only have symfony-standard right now.. but still- It shouldn't look like this by my opinion

from platform.

I'm also investigation the oro platform to use it as part of a project. Do you guys have plans to make parts of the bundle more modular and individually installable via composer? Kinda like the Sylius Project.

from platform.

@dmitriysoroka Right now I'm having a problem to understand this structure...
If the platform was built properly, and there was actually way to understand whats going on there.. I was certainly consider using it(there are some cool bundles over there).. or at least some of the bundles... in my company.
If I were use it, probably I(& my company) were contribute to the code.. and it was encourage me to use ORO over the competitors..

So, in matters of open-source, ordered and welcomed code is helping to increase the community..
I'm pretty sure that's i'm not the only one.. and some of this bundles are great!(like the merge-entity)- so a lot of project can use them and develop them to even better level!

You may consider this reasons...

from platform.

Thanks for your feedback @AlmogBaku . Let me clarify the situation around Oro packages as I’m not completely clear what are your concerns about the way the platform built. OroCRM and Oro Platform are distributed as standalone packages:

• https://github.com/orocrm/platform - Platform bundles
• https://github.com/orocrm/crm - CRM bundles

Both packages have a set of bundles that are related to their domains and OroCRM package depends on the Platform package. In such a way Platform can be used independently from OroCRM as a foundation for any other application.

You can create your own application and start using platform with defining proper dependency and bundles initialization or you canst start from platform-application or crm-application repositories.

The model is very similar to symfony-standard application that has dependency on symfony framework except availability of each bundle as a standalone package. We understand all benefits of resolving this issue but unfortunately will not be able to work on it in the nearest future. For now we would like to hear which bundles really have the need and demand to be used independently and would love to get contributions that will allow to separate them.

Please let me know if you have any other concerns or questions.

from platform.

each bundle has a composer.json file already. so if things like your MenuBundle or the MigrationsBundle would be usable outside the context of oro, it would be great to provide them separately so that they can be used in any project. The approach could be similar to what symfony itself is doing, with a master repository at symfony/symfony but subtree-split to provide each component standalone.

from platform.

I'm with you, please feel free to submit a pull request. We already have a couple of bundles that can be separated and will invest in this direction more.

from platform.

well the main thing to do is setup those subtree splits and there is no PR one can do for this ..

from platform.

@lsmith77 not sure i understood you, what is the problem with PR?
We'll work on subtree splits but in order to separate a bundle we need help on making it independent from other bundles (or depended on the ones that already separated) and this PRs could be submited to platform repository.

from platform.

@DimaSoroka you can't PR new repository- the maintainer should open a new repo under the "orocrm" user...

from platform.

@AlmogBaku sorry, but i still not clear on issue with PR, please explain.
You should be able to fork repo, do necessary changes and submit the pull request to our repo. Do you have any issues with this?

I clearly understood the need for repository split and we'll work on this, but it should not be a blocker for bundles code fixes and PRs.

from platform.

Hi

We're very interested in some of your bundles too for eZ Platform 😉
@DimaSoroka What I can do is giving an example on how to split one bundle up and give you the script I use for this, to keep everything in sync. Does it sound OK to you?

from platform.

Here what I ended up with:

• Config component
• DistributionBundle

I created a gist explaining how to set it up, it's very simple 😄

Only drawback is that I only managed to get tags and master branch. All other branches are still missing, but I guess that's a good start

from platform.

Thanks @lolautruche, this is helpful and a good start, will test it out

from platform.

Created a tool based on proposed tool and published RequireJSBundle. Everything looks fine except tags information, for example 1.0.0-altha3 tag is empty as bundle was created later.

Also published DistributionBundle and ConfigBundle.

Please let me know if it looks correct and what are your needs for other bundles.

from platform.

Very cool, thanks @DimaSoroka !
Can you please add them to Packagist?

I'll a couple of PRs to ensure they're individually usable.

from platform.

Sure, added them to Packagist, waiting on your PRs.

from platform.

Closing this issue, please feel free to request other bundles separation and participate in decoupling process.

from platform.

Hi @DimaSoroka

oro/requirejs-bundle is well installable via packagist

oro/distribution-bundle cannot be installed through packagist because it requires oro/config (the component, not the bundle). It can be fixed by spliting oro/config and register it on packagist

oro/config-bundle cannot be installed because it requires :

• oro/config: dev-master (OK once component registered)
• oro/requirejs-bundle: dev-master (OK)
• oro/ui-bundle: dev-master (KO)
• oro/user-bundle: dev-master (KO)

This one will be harder to provide as standalone package because depends on user-bundle which requires a lot of others bundles. BTW, there is a typo in composer.json because it requires Symfony 2.1.*

Could you split and register oro/config component ?

Thank you !

from platform.

This one will be harder to provide as standalone package because depends
on user-bundle which requires a lot of others bundles. BTW, there is a
typo in composer.json because it requires Symfony 2.1.*

for reusability, it would be nice if oro/config-bundle would be able to
work without the user-bundle. providing optional components that the
user can use when he uses the oro user-bundle, but not fail if its not
installed.

user-bundle indeed depends on a lot of things. i doubt that the user
interface things (ui, soap, grid, navigation, form) are needed when the
config-bundle integrates user level configuration.

in terms of good separation of concern, maybe a user /component/ would
make sense that only provides the models and logic without the admin ui.

in the user-bundle composer.json i noticed that you depend on dev-master
of all other oro things. this is really not good practice - if you ever
introduce bc breaking changes, users will be screwed. you should depend
on "~1.0" if you properly do semver and expect no BC breaks within the
1.x line.

for the symfony requirement, it should probably be "~2.3" rather than
"2.3.*" which prevents symfony 2.4 and later.

from platform.

Thanks @nidup, oro/config created.
@dbu, right now we are not planning to invest a lot into decoupling effort but we are very open to review PRs and assistance.

from platform.