Additional Submodules?

[gregorydlogan]

Hi all,

In the technical meeting today we talked about potentially making paella8 a submodule. While a number of us were ok with this, there were some objections and suggestions on how to better approach this if we go ahead.

The initial approach suggested was to move the current glue code into a subdirectory of the current module (so something like modules/engage-paella-player-8/paella) keeping our pom file in the main repository to simplify the branch bookkeeping.

The counter argument presented was that we should not be adding submodules outside of Opencast's org as direct submodules, and that we want to continue to have buildability if for some reason you don't have the code checked out. A suggestion was made that we move the engage-paella-player-8 module into its own repository, like admin, editor, and studio, and then make that repository a submodule. This would also preserve buildability since your .m2 would have the last built version of the module rather than requiring a fresh build each time.

So, in summary here:

• I would like to see consensus on whether we move Paella8 into any kind of submodule or preserve present behaviour
• If we move to submodules do we add the submodule directly to opencast/opencast, or do we create a separate repo that effectively nests the submodule?

Not that I am expecting a huge number of additional submodules to be added, but when considering the above make sure to think about what your vote would be for some other module to be added to the build. We should, ideally, be doing more or less the same thing for every submodule in the global opencast/opencast project.

[mtneug]

Git submodules bring a certain complexity. If possible, I would avoid them and use classical dependencies (e.g. node package). In any case, I would agree that submodules should only point to repositories in the Opencast GitHub org.

[KatrinIhler]

A suggestion was made that we move the engage-paella-player-8 module into its own repository, like admin, editor, and studio, and then make that repository a submodule.

That sounds reasonable, from my very naive perspective :D

[miesgre]

The main issue I'd like to address is that the paella-8 module in Opencast (link) is essentially a duplicate of the code in the paella-opencast repository (link). Whenever there's a change in one repository, I have to be careful to manually synchronize the other.

I would like to solve this. For debugging convenience—especially when libraries are updated—the source code should ideally live exclusively in the paella-opencast repository.

My proposal is to remove the source code from the Opencast module entirely and replace it by either downloading the pre-compiled code (via a GitHub release .tgz or npm) or by setting up a Git submodule.

Option 1: Download pre-compiled code (TGZ or NPM)

Downloading a .tgz file directly from a GitHub release (e.g., engage-paella-player@8.0.1) works perfectly fine for me. This is similar to how Studio and the Admin UI used to be handled in the past (I'm not sure if there were specific issues with that approach that prompted the move to submodules, or if it was for another reason).

Alternatively, we could fetch the engage-paella-player package via npm. We don't currently publish this specific package to npm, but we could start doing so. It might be slightly unusual since it would just be the pre-compiled engage player rather than a standard npm library, but I don't see any real issues with doing it this way.

Option 2: Git Submodule

If we decide to go the submodule route, it would need to be implemented differently than the current ones (where the pom.xml resides in the external repository, like with the Admin UI).

Because paella-opencast is a monorepo containing several npm packages, it doesn't align well with Opencast's branching structure. Therefore, the pom.xml file should remain in the Opencast repository, and we could create a subfolder (e.g., paella-src) to act as the submodule pointing to the specific version we want to include.

Conclusion

From my perspective, either downloading the .tgz release from GitHub or fetching the package via npm would be the simplest and most sufficient solutions. I'm happy to hear your thoughts on which direction we should take!

[gregorydlogan]

Hey @miesgre, in discussion today at the technical meeting there was a preference for Option 1 as well. I would be tempted to just pull the admin/editor/studio pom history and adapt that rather than publishing to npm - unless that's something on your wish list.

[tyfranck]

Prior to adopting Paella 8, Opencast was using NPM which made sense. No clear idea why it was changed but I go for Option 1 too.
That's how we're implemented Paella 7/8 for our video portal.

[karendolan]

Our site adds a bunch of overrides and additional plugins for Paella that live in our Opencast paella-player module and are injected during module build. I'm curious how that would work, in addition to dev & debugging, with Option 1 going forward?

[gregorydlogan]

I would fork Paella 8 into DCE's namespace, and apply your patches there. Then change the Maven module to download your releases from your fork.

[miesgre]

Our site adds a bunch of overrides and additional plugins for Paella that live in our Opencast paella-player module and are injected during module build. I'm curious how that would work, in addition to dev & debugging, with Option 1 going forward?

Greg is right

I would fork Paella 8 into DCE's namespace, and apply your patches there. Then change the Maven module to download your releases from your fork.