-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move bundled apps to market #27542
Comments
To be "Done" an item must:
|
Trashbin and versions have some cross-dependencies between each other and also some core code depends on them. They can be disabled and OC might work fine though. |
The files_sharing app can be disabled too, even removed. But some code pointing to the sharing app is hard-coded in core. |
i would suggest to keep core apps in the release - just because of simplicity reasons. just my 2 :cents: |
Ok, I did a local test on master and I removed ALL app code except the always_enabled ones:
Surprisingly the platform still boots up 😄 However I suspect that one might encounter small issues here and there for the apps that are referenced directly by core. It should be possible to quickly find these references and make them conditional to be able to have such minimal platform. |
@DeepDiver1975 so all apps that are already in the "core" repository stay bundled, and apps that are in separate repos go to the market ? |
yes - plus that we can ship apps from separate repos as well - e.g. market app |
@PVince81 will unbundled apps still be marked as |
I'd remove them from |
user_ldap has already been moved out of the release due to issues. It's next release will be in the marketplace. |
@IljaN Any update ? What's the status ? (checkboxes...) |
Idea for moving out files and files_sharing: merge both apps into a single app "files". To disable sharing, one can always use the existing checkbox in the admin page. When moving the "files" app to the marketplace, it would then also contain the sharing UI stuff. This would solve the dependency that files_sharing has on files. |
It turns out files_sharing is doing too much:
One idea from @DeepDiver1975 is that we keep files_sharing in core as a pure backend app with no dependencies on the "files" app. Currently the only dependency I see is on the JS side, for example when buildling download URLs based on the files app routes. So we should only move this sharing related JS code to the "files" app. |
Any more apps to move out for 10.0.3 ? I suggest we stop now and continue this for 10.0.4, moving to "planned" |
@IljaN @DeepDiver1975 we should continue this now |
the next I think would be good to look at, in order:
|
|
or instead of #27542 (comment) we could move the JS code from the files_sharing app into another app files_sharing_ui. This would make it possible to extend sharing UI through a marketplace app as much as the APIs allow. |
@VicDeo can you continue to prepare the unbundling of apps ? then we can queue them into the QA pipeline for later |
@PVince81 we are unbundling templateeditor for over 3 months so far. Notifications are ready for the process as well. |
first run wizard, video player ? |
firstrunwizard owncloud/firstrunwizard#72 |
@PVince81 templateeditor has been published in the market and could be excluded from the release package https://marketplace.owncloud.com/apps/templateeditor |
@VicDeo yes, done by @patrickjahns so it will be removed in the 10.0.8 RC |
moving to backlog. let's schedule explicitly what apps to process next |
The files_sharing app contains both frontend and backend components currently. |
I'm not sure about the responsabilities of each component then. Core is just acting as a hub of sharing providers? What will be the responsability of the files_sharing app? Currently, I think the files_sharing app is providing a frontend for the sharing, as well as the sharing API. The shared storage is also provided by the app... but the default share provider is in core... This is really confusing. One proposal could be:
The problem in this case is that the frontend app will depend on another app. I feel that, unless we come to an agreement about what components will be involved in sharing, how they will interact with each other, and where each component will be placed, it will become even more messy than what we have right now: both apps and core will need each other, so there is no real decoupling, and we'll also need to handle 2 apps and core, not just one app and core |
In the case of Phoenix which will be a separate frontend, we had a chat and I think we agreed that so far some apps will need to have two components: a backend app to install on the PHP server and a frontend app to install on the frontend. It is not clear yet how the dependency will be enforced. |
Next apps to address:
both already have a separate repo but aren't unbundled in stable10. from what I heard user_management isn't ready yet as it causes regressions when removed from a core: #31739 |
This issue has been automatically closed. |
The following apps are currently bundled in the ownCloud server community release.
Some apps come from the core repo, some from their own.
The text was updated successfully, but these errors were encountered: