Uploaded image for project: 'PUBLIC - Liferay Portal Community Edition'
  1. PUBLIC - Liferay Portal Community Edition
  2. LPS-74291

Unpublish Calendar upgrade processes exported by calendar-service



      In portal, there is an old pattern where we extend an upgrade process to test it. This way, we have access to its protected methods and the testing can be quite easier.

      This pattern, however, does not work when testing OSGi modules, except if it exports the upgrade process. Exporting upgrade processes, however, is not a good practice in general because they are more like an implementation detail. As an alternative to test them, we have tests retrieve the upgrade process from the OSGi registry. A good example can be foudn in UpgradeDynamicDataMappingTest.java.

      Some upgrade processes from calendar follow the old pattern, though, because they predate the modularization. One of these is com.liferay.calendar.upgrade.v2_0_0.UpgradeSchema. It is exported to be tested. However, since it is related to a story that was merged before modularization but not yet released, the v2_0_0 package is not yet released. This means we can refactor the code to not export this class as well.

      The other case is com.liferay.calendar.upgrade.test.UpgradeCalendarTest. In this case, however, the upgrade process was published in DXP. Yet, we can deprecate it as a published API.

      This tasks consists on unpublishing UpgradeSchema and deprecating UpgradeCalendar as an external API.




            • Assignee:
              adam.brandizzi Adam Brandizzi
              adam.brandizzi Adam Brandizzi
              Recent user:
              Lester Pi
              Participants of an Issue:
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created:


                Version Package