Library that allows to setup a number of Liferay artifacts in the DB. It uses xml and Liferay APIs to add all configured artifacts.
We recommend wrapping the library calls in either Liferay upgrade process or in a control panel app for a reset to defaults application.
All data definitions in examples are applied according to XML file header which defines on which company data creation should take effect and which admin user should be used for data creation.
<?xml version="1.0" encoding="UTF-8"?> <setup xmlns="http://www.ableneo.com/liferay/setup"> <configuration> <!-- run as automatically selected admin --> <company> <companywebid>liferay.com</companywebid> </company> </configuration><?xml version="1.0" encoding="UTF-8"?> <setup xmlns="http://www.ableneo.com/liferay/setup"> <configuration> <run-as-user-email>admin@my.web.com</run-as-user-email> <company> <companywebid>liferay.com</companywebid> </company> </configuration>Resource permissions.
<resource-permissions> <resource resource-id="my.custom.resource.string"> <actionId name="SPECIAL_PERMISSION"> <role name="My Role"/> <role name="Your Role"/> </actionId> </resource> </resource-permissions>Resource permissions are set per company are verifiable with followin API call.
permissionChecker.hasPermission( groupId, "my.custom.resource.string", companyId, "SPECIAL_PERMISSION" );Portlet permissions.
<resource-permissions> <resource resource-id="myportlet_WAR_portlets"> <actionId name="VIEW"> <role name="User"/> <role name="Guest"/> </actionId> </resource> </resource-permissions>Following snippet creates expando attribute canonical-url with permissions to view by guest user.
<custom-fields> <field name="canonical-url" type="string" class-name="com.liferay.portal.kernel.model.Layout"> <role-permission role-name="Guest" permission="view"/> </field> </custom-fields>Site element must always have site-friendly-url attribute. Guest site is determined by default attribute with true value. All content like pages, articles, documents etc. is always created within a specific site.
<sites> <site default="true" site-friendly-url="/guest"> </site> <site default="false" site-friendly-url="/admin"> <name>Admin</name> <name-translation locale="en_US" text="Admin"/> </site> </sites>Files new_structure.xml and new_structure_template.ftl are deployed as a part of a module that is using the db-setup-core library and reside in it’s classpath.
<site site-friendly-url="/admin"> <article-structure key="NEW-STRUCTURE-KEY" path="new_structure.xml" name="New Structure"/> <article-template key="NEW-STRUCTURE-TEMPLATE-KEY" path="new_structure_template.ftl" article-structure-key="NEW-STRUCTURE-KEY" name="New Structure Template" cacheable="true"/> <name>Admin</name> </site>File artcle.xml is deployed as a part of a module that is using the db-setup-core library and reside in it’s classpath.
<sites> <site> <article title="Article Title" path="article.xml" article-structure-key="NEW-STRUCTURE-KEY" article-template-key="NEW-STRUCTURE-TEMPLATE-KEY" articleId="ARTICLE_ID"> <tag name="product" /> </article> </site> </sites>-
Install the
com.ableneo.liferay.db.setup.core-7.3.601.jarbundle in${liferay.home}/osgi/modules -
Prepare your own bundle that uses the library as a
provided/compileOnlydependency. For example:build.gradledependencies { compileOnly 'com.ableneo.liferay:com.ableneo.liferay.db.setup.core:7.3.601' }pom.xml<dependency> <groupId>com.ableneo.liferay</groupId> <artifactId>com.ableneo.liferay.db.setup.core</artifactId> <version>7.3.601</version> <scope>provided</scope> </dependency>
-
Prepare xml data configuration. Documentation sits directly in the setup_definition.xsd file.
Example documentation
Example configuration: setup.xml<?xml version="1.0" encoding="UTF-8" ?> <setup xmlns="http://www.ableneo.com/liferay/setup"> <configuration> <!-- uses random administrator account for the setup in the company, run-as-user-email tag allows to specify particular admin account to be used for the setup --> <company> <companyid>20101</companyid> <!-- companywebid can be used alternatively --> </company> </configuration> <sites> <site> <!-- Guest by default --> <vocabulary name="Some categories" uuid="602f55b6-6021-455e-8d6d-696cc25daa91"> <title-translation locale="de_DE" text="Einige Kategorien"/> <category name="Other categories" uuid="867b33df-2465-4a81-9945-88159c604589"> <title-translation locale="de_DE" text="Andere Kategorien"/> <category name="New category" uuid="5fb4308e-bd21-4cf4-bdc5-3557508ffe4a"> <title-translation locale="de_DE" text="Neue Kategorie"/> </category> </category> </vocabulary> </site> </sites> </setup>
-
Load the XML setup file and run
setupmethod on it:URL resource = Thread.currentThread().getContextClassLoader().getResource(path); InputStream setupFile = Objects.requireNonNull(resource, "XML Liferay DB setup file not found in classpath.").openStream(); Setup setup = MarshallUtil.unmarshall(setupFile); boolean setupSuccess = LiferaySetup.setup(setup);
The code is compatible with Liferay Portal 7.3.6. Other versions that have been or are supported:
-
more tests
-
project integration with lundegaard fork: https://github.com/lundegaard/liferay-db-setup-core, until than changes and fixes from lundegaard fork will be ported to the library
We use Liferay as an application building platform.
Portlets, content and permissions, in short- data serve as a building block of a web application with consistent portal UX. In the use case the data play important role in application building, greatly influencing UX.
By storing the application data as XML declaration we enable developers to version and progress data development as if it was a code. All standard development practices like versioning, code review, building and deployment can be applied to the Liferay data as code.
Want/need to hack on db-setup-core? See our super short contributing guide for information on building, testing and contributing changes.
They are probably not perfect, please let me know if anything feels wrong or incomplete.
-
target Liferay Portal version is still minimum 7.3.6 (GA7)
-
fix: add individual resource for permissions setup in case there are declared not for portlet but a
model-resource, allows to usehasUserPermissionmethod for the custom resource id string and aprimKey = companyIdFixed configuration<resource-permissions> <resource resource-id="custom.resource.id-not.a.portlet.id"> <actionId name="SOME_PERMISSION"> <role name="Some Portal Role"/>
-
Bumped target Liferay Portal version to minimum 7.3.6 ga7.
-
Improved category/vocabulary idempotency, it’s possible to update categories and vocabularies with optional uuid, before categories/vocabularies were identified only by name. That allows to update a category name which wasn’t possible before.
-
Improved categories/vocabulary updates performance, update is only issued if anything in the definition differs compared to the data in the DB.
-
Category by_name search is scoped only to a particular vocabulary.
-
Added property element in categories that allows to define AssetCategoryProperty. These are identified by a key.
TipTODO: deletion of existing property.
-
divided xsd to "elements" and "types" parts, replaced many element references with types which improves naming flexibility
-
every xsd type follows is camel cased and suffixed with word: Type, e.g. UuidType
-
simplified dependency management with
release.portal.bom -
removed
shademaven plugin as portal exportscom.liferay.portlet.asset.utilpackage already inorg.eclipse.osgi_3.13.0.LIFERAY-PATCHED-11bundle
-
OSGI descriptors in JAR, the bundle can be deployed and work as a standalone Liferay 7.x bundle
-
instance import feature added, credit goes to @bimki - thank you!
-
portal properties feature added, credit goes to @fabalint - thank you!
-
new helper methods to run the setup (ported from 1.x branch):
-
com.ableneo.liferay.portal.setup.LiferaySetup#setup(java.io.InputStream) -
com.ableneo.liferay.portal.setup.LiferaySetup#setup(java.io.File)
-
-
fixed categorization idempotency (vocabulary and category name handling)
-
fixed language handling for groups
-
improved javadoc in entrypoint
com.ableneo.liferay.portal.setup.LiferaySetupclass -
upped dependencies to Liferay 7.3.5, credit goes to @fabalint - thank you!
-
changed versioning so that major.minor.patch version reflects target platform, build version will be used to track changes in the library
-
documentation format conversion from markdown to aciidoc
-
added slf4j and changed logger in few classes for more ergonomic log message interpolation (Liferay 7.x provides slf4j by default)
-
added prettier formatter to the project
-
added build environment setup automation with nix
-
it’s possible to use more than one company id per configuration file, the configuration will be applied to all listed companies
-
tag names in configuration follow unified naming convention: word-word
-
run-as-user renamed to run-as-user-email to be explicit about expected value
-
added missing documentation to few xml elements
-
setup xsd provides a version attribute
-
configured sonar analysis on each commit
-
configured maven test / coverage runner
-
maven project structure has changed to single-module
-
companyId, groupId and runAsUserId are set in Setup class and propagated to all involved Utils with SetupConfigurationThreadLocal context class
-
improved MarshallUtil performance
-
introduced unit tests
-
most of the problems reported by sonar are fixed
-
improved logging