cancel
Showing results for 
Search instead for 
Did you mean: 

Include / Multiple Local.Properties

Former Member
0 Kudos

Hi All,

We currently have application, environment and functional configurations in a single local.properties file.

Is there an option to,

  1. have multiple local.properties that can be loaded?

  2. include files into local.properties so that configuration can be split as per the nature.

Any help around this will be great.

Regards

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello,

hybris has only one local.propertie file, and it is designed to replace already defined properties.

Including multiple such local.propertie files is not yet considered for the near future.

Regards,

Lin

Former Member
0 Kudos

Thanks Lin!!

Answers (4)

Answers (4)

Former Member
0 Kudos

hi @Gerard , I am also in the same situation as , would like to what is the work around to load multiple properties files from config location. As per the project need we would like to split feature wise as have more properties then expected. I saw you have mentioned above the hard coding into system, can you share some details on the same , would appreciate your early response.
Thanks in advance.

Former Member
0 Kudos

ydeploy is an open source deployment framework for hybris which provides support for "layered" configurations and would likely help with your needs.

By default, ydeploy allows you to store your hybris configuration properties at one of three different levels:

  1. Global configurations (global.properties)

  2. Environment configurations (e.g. dev.properties, qa.properties, prod.properties)

  3. Server / Instance configurations (e.g. dev01.properties, dev02.properties, qa01.properties, etc)

Configuration values can exist at any of the levels with the configuration values at the latter levels taking precedence,

When you run the hybris build process, ydeploy will merge the appropriate configurations together to generate the effective local.properties.

For example, if you were to run the hybris build in your "dev" environment on the "dev01" server, ydeploy would merge global.properties, dev.properties, and dev01.properties to produce the local.properties.

More information can be found on the ydeploy site.

http://avatria.github.io/ydeploy/

ArthurPerry
Employee
Employee
0 Kudos

local.properties should be used for environment specific values, i.e. values that will change from DEV to QA to UAT to PROD. Any other externalized values (as you say: functional and application) should be maintained in project.properties for each of your custom extensions. If you use the modularity of the extensions concept correctly, this should allow you to have very manageable properties files.

Further, with respect to environment specific properties, there is a (not very well documented) feature of the hybris ant build system. If you set a system property useconfig you can switch local.properties to alternate files for different environments. This is very handy if you want to store all your different local.properties versions in the source control system. Usage:

In my config folder I have:

  • local.properties

  • localDEV.properties

  • localPROD.properties

    ant -Duseconfig=DEV all

This will execute the build using localDEV.properties.

Former Member
0 Kudos

Hi Arthur,

Thanks for the reply. Completely make sense!!

former_member602476
Active Participant
0 Kudos

Hi Art, good point on separate properties files for environment, this is what we've seen work best, however last time I saw -Duseconfig used, things were not working very well. While it will use the correct database settings, or any hybris specific settings, it would actually not use any values that you defined for tomcat or server.xml such as tomcat.generaloptions, or any properties that you need to go into server.xml after an ant. I don't think this is intended for production use.

former_member602476
Active Participant
0 Kudos

What I've seen work best is in your specific environment you could have part of your deployment a task to link local{env}.properties to local.properties in your specific environments

Former Member
0 Kudos

Hi, OOTB there could be only a single local.properties (for the platform) and it is hard coded into the system (e.g. bootstrap, ant, etc.). However, may I know the purpose of having multiple local.properties or splitting local.properties ?

Thank you. Regards,

Gerard

Former Member
0 Kudos

Hi Gerard,

Right now, we use the local.properties and added configuration like,

  1. Java options

  2. DB

  3. Application specific

We foresee that on long run the file might grow.

So, we are looking at,

  1. Split the configurations into multiple files (or)

  2. Have one local.properties and include other configuration files into it

Regards, Siva