Be able to specify script constraints

[pun-ky]

Final decision:

Script naming:

• prechecks.groovy
• script1.prechecks.groovy
• script1.groovy
• script2.groovy
• script3.groovy

prechecks.groovy would be the default for the whole folder. script1.prechecks.groovy would override the default for script1.groovy. Prechecks are optional. If no such script exists then execution will be as before.

---

For instance, I'd like to have an ability to implement Groovy Script that is executable only, if currently deployed CRX Package -> OSGi bundle has at least x.x.x version. This will protect against runtime execution errors and provide a way for implementing scripts earlier, that will be executed later automatically (if constraint will met).

What do you think about that feature? Could you consider implementing this / addressing somehow?

[gruberrolandvaltech]

I think these constraints should be checked in the script itself. There are various possible constraints and it would be too much effort to implement all of them in the install hook or GUI.

You could simply add some section at the beginning of your script that gets the bundle version. This can be done with https://osgi.org/javadoc/r4v43/core/org/osgi/framework/FrameworkUtil.html

[pun-ky]

Imports must be at the beginning of the script so that this is not realizable 😉

I mean if (checkAppVersion()) import com.company.xxx and all the rest.

Correct me if I am wrong

[gruberrolandvaltech]

Yes, but the imports should not do any harm. They can be executed in any case as long as the import does not depend on the tested bundle, does it?

[pun-ky]

They will depend. That's the case exactly.

I am thinking about

Sample.groovy and Sample.constraint.groovy

Aecu firstly executes constraint. If it is ok / return true executes main script with no classifier.

What do you think.?

[pun-ky]

And there are convenient methods added to aecu to check bundles and crx package versions to simplify constraint scripts

[gruberrolandvaltech]

I think putting the constraint in the file name is not a good idea. This will be very hard to read. Currently, AECU does not provide any methods to check bundle versions or CRX package versions. This would not really match the used builder pattern. But GroovyConsole itself already has similar methods. Maybe they can add it directly?

Not sure if run modes would help in your case?

Otherwise, you could try to use full qualified class names where you are not sure if the bundle exists. Not sure if this would be executed without ClassNotFoundException.

[pun-ky]

You don' get it 😉 the idea is to support by aecu a script executed before main script that checks if the second one could be executed.

Sample.constraint.groovy contents:

return Version.from("y.y.y") > Version.from(getBundleVersion("com.company.example"));

Sample.groovy contents :

import com.company.example.MyService;

<any groovy script content without constraints inside, because they are checked in previous constraint script >

[gruberrolandvaltech]

Ok, so you mean something like this in a folder?

• aecu_prechecks.groovy
• script1.groovy
• script2.groovy
• script3.groovy

aecu_prechecks.groovy would be executed first and only if it does not throw an error the other scripts would be executed.

[pun-ky]

Yes but rather per script. Not per folder.

[gruberrolandvaltech]

So something like this?

• .prechecks.groovy
• script1.prechecks.groovy
• script1.groovy
• script2.groovy
• script3.groovy

.prechecks.groovy would be the default for the folder. script1.prechecks.groovy would override the default for script1.groovy.

[pun-ky]

Yep will be okay but on windows leading dot in filename is problematic😉

[gruberrolandvaltech]

Oh, thanks for the hint. :) Will put the final naming in first post then.

[gruberrolandvaltech]

Hi @pun-ky,

sorry that this got deprioritized so long, Is it still an issue or could this also be solved using run modes?

[pun-ky]

About contrains I mean that they could check if app is already installed. I cannot do that using runmodes so the origin problem cannot be solved. No worries, it's nice to have it.

[gruberrolandvaltech]

Took some time but finally implemented: https://github.com/valtech/aem-easy-content-upgrade/pull/174