Automating creation of versioned distributions

Support
#1

Hi

We aim to automate creation of war distributions, especially for production, and are looking for guidance on how to integrate our process with Cuba, which is already very integrated by itself.

Mostly, we fear that if we customize build.gradle and tomcat deployment, everything can later be made disappeared by Studio (who can delete both of those in certain cases).

Our process would be designed this way:

  1. Artifact version is taken from Git branch and set into build.gradle : is there any facility in Cuba to do that ?
  2. Datasource must be changed according to environment (homologation, production) in META-INF/context.xml into the war produced by Studio : how can we hook into Studio war generation to do that ?
  3. put a logback.xml specific for production : same here, how can we hook into war generation to add the file to war

Any guidance would be much appreciated.

Mike

1 Like
#3

Someone could provide insights on this ? Most of Cuba platform users delivering to production should have met the same questions or equivalent ones.

Your input would be much appreciated.

Mike

#4

Hi Mike,

First of all, about safety of your manual changes in build.gradle. For quite a long time, the only case when Studio rewrote build.gradle and settings.gradle was when you changed “module prefix” for the project. In the recent versions, even this case was eliminated: now new projects have modulePrefix variable in both files, so they never have to be rewritten. It means that Studio never deletes your changes, it only modifies specific parts of the scripts when you change project properties in UI.

Now about your questions.

  1. You can provide parameters corresponding to the cuba section of build.gradle on the command line, for example:

    gradlew assemble -Pcuba.artifact.version=1.0 -Pcuba.artifact.isSnapshot=false

  2. Use coreContextXmlPath parameter of the buildWar task to provide a context.xml file to be used in production. It can also be set from Studio UI:
    image

  3. Use logbackConfigurationFile parameter of the buildWar task (not yet documented). It must be a path to your desired production logback.xml relative to the project root. You can also just put logback.xml in the classpath root of your global module, and it will be copied to JAR together with classes and found by Logback init procedure when your server starts.

1 Like
#6

Perhaps it would be better to pass version in a full form -Pcuba.artifact.version=1.0-SNAPSHOT and don’t pass -Pcuba.artifact.isSnapshot=true et all since it looks as if there is a magic in CUBA plugin or somewhere else which tackle with isSnapshot.
To illustrate this I added println "isSnapshot=${cuba.artifact.isSnapshot}" to uploadRepository section in build.gradle

ilia@ubuntu:~/cuba-6.8-ci$ ./gradlew -Pcuba.artifact.version=1.0 -Pcuba.artifact.isSnapshot=true  --refresh-dependencies clean assemble -x test uploadArchives

> Configure project : 
isSnapshot=false
...

ilia@ubuntu:~/cuba-6.8-ci$ ./gradlew -Pcuba.artifact.version=1.0-SNAPSHOT -Pcuba.artifact.isSnapshot=false  --refresh-dependencies clean assemble -x test uploadArchives

> Configure project : 
isSnapshot=true
...
1 Like
#7

2 posts were split to a new topic: How to add groovy ConfigSlurper dependency

#8

It seems not working for WAR : “You can also just put logback.xml in the classpath root of your global module, and it will be copied to JAR together with classes and found by Logback init procedure when your server starts.”

As advised I put a logback.xml in root of global src :

image

But in my war I had a default logback.xml in web-inf/classes instead of mine :
image

EDIT : but it works using undocumented logbackConfigurationFile in build.gradle.

task buildWar(type: CubaWarBuilding) {
    [...]
    logbackConfigurationFile = "/modules/global/src/logback.xml"
}
#9

You are right, it turned out that placing your logback.xml in the classpath root is not enough. There is one more not (yet) documented parameter of the buildWar task: useDefaultLogbackConfiguration. Until you set it to false the task copies its own standard logback.xml.