Site configuration

---

Structure of site sources

The source directory of a Lutèce site has the following structure:

• pom.xml
• src/
  • conf/
    • default/ : the content of this folder takes up the structure of the WebApp that will be deployed
    • rec/ : the content of this file takes up the structure of the WebApp that will be deployed
    • prod/ : the content of this file takes up the structure of the WebApp that will be deployed
    • ...
  • sql/ : the content of this folder takes up the structure of the WEB-INF/sql/ folder of the WebApp that will be deployed
  • site/ : the content of this folder takes up the structure of the folder doc/xml/ of the WebApp that will be deployed
• webapp/ : the content of this file takes up the structure of the WebApp that will be deployed

Only the pom.xml is mandatory.

File overload mechanism when building the WebApp

When building the site, files from different sources are copied to the WebApp. If a file from one of these sources is already present in the WebApp, then the old file will be replaced by this one. The files are copied in the following order:

• 1 - files provided by the Core Lutèce
• 2 - files provided by the Lutèce components (dependencies of type lutece-plugin )
• 3 - files brought by Lutèce sites (dependencies of type lutece-site )
• 4 - jar files provided by the other dependencies (dependencies of the type jar ) copied in WEB-INF / lib/
• 5 - files present in the webapp/ folder on the site
• 6 - files present in the site's src/sql/ folder copied into WEB-INF/sql/
• 7 - files present in the src/site/ site folder copied to doc/xml/
• 8 - files found in the site's src/conf/<profile>/ folder

The value of <profile> corresponds to one of the maven profiles defined in Lutece-site-pom and used at the time of construction of the webapp or default if none of these profiles is used. The maven profiles defined in Lutece-site-pom are as follows:

• dev
• rec
• integ
• training
• preprod
• prod

See How lutece-maven-plugin works for more information.

Example of file overload

Let's take the example of an XYZ site that uses an ABC plugin.

The ABC plugin has a template in :

(...)/plugin-ABC/webapp/WEB-INF/templates/skin/plugins/plugin-ABC/mytemplate.html (plugin)

In the WebApp, the plugin template will be copied into :

(...)/site-XYZ/target/site-YYZ-1.0.0-SNAPSHOT/WEB-INF/templates/skin/plugins/plugin-ABC/mytemplate.html (plugin)

If now we add a modified ABC plugin template to the site sources :

(...)/site-XYZ/webapp/WEB-INF/templates/skin/plugins/plugin-ABC/mytemplate.html (site)

In the WebApp, this template will replace the one from the plugin :

(...)/site-XYZ/target/site-YYZ-1.0.0-SNAPSHOT/WEB-INF/templates/skin/plugins/plugin-ABC/mytemplate.html (site)

If we add another modified template in the site sources for the rec profile :

(...)/site-XYZ/src/conf/rec/WEB-INF/templates/skin/plugins/plugin-ABC/mytemplate.html (site/rec)

In the WebApp built with the rec profile, this template will replace the one from the site :

(...)/site-XYZ/target/site-YYZ-1.0.0-SNAPSHOT/WEB-INF/templates/skin/plugins/plugin-ABC/mytemplate.html (site/rec)

Mechanism of overloading properties and beans when starting the WebApp

When the WebApp starts, the properties of the site components and the Spring beans are loaded from the files contained in /WEB-INF/conf/. If one of these files brings a property or a bean already loaded, then the old property or the old bean will be replaced. The files are read in the following order:

• 1) Read the Core files in /WEB-INF/conf/
• 2) Read plugin files in /WEB-INF/conf/plugins/
• 3) Read the core overload files in /WEB-INF/conf/override/
• 4) Read plugin overload files in /WEB-INF/conf/override/plugins/

The files in points 1) and 2) come from the Core and from the site components if they were not overloaded during the construction of the WebApp. The files of points 3) and 4) can be brought by the site.

Good Practices

The files placed in /WEB-INF/conf/override/ :

• must correspond to the files placed in /WEB-INF/conf/ in order to easily know where the properties or the overloaded beans come from.
• should not include all the properties or all the beans of the files placed in /WEB-INF/conf/ but only those which must be modified in order to easily know what overloads have been made.

Example of property overload

Using the example of the XYZ site which uses the ABC plugin :

The ABC plugin has a property file in :

(...)/plugin-ABC/webapp/WEB-INF/conf/plugins/abc.properties

which contains the following properties :

abc.myproperty1 = value1
abc.myproperty2 = value2

If we add an overloaded property file corresponding to that of the ABC plugin in the site sources :

(...)/Site-XYZ/webapp/WEB-INF/conf/overrude/plugins/abc.properties

containing the following property :

abc.myproperty1 = value_override

The two files will be found in the WebApp :

(...)/Site-XYZ/target/Site-YYZ-1.0.0-SNAPSHOT/WEB-INF/conf/plugins/abc.properties
(...)/Site-XYZ/target/Site-YYZ-1.0.0-SNAPSHOT/WEB-INF/conf/overrude/plugins/abc.properties

and after starting the WebApp the values ​​of the properties will be :

Mechanism of overload of the labels during the construction of the pages

See Internationalization (i18n) for more information.