Expand my Community achievements bar.

SOLVED

Embed license.properties in quickstart jar ?

Avatar

Level 2

Hi,

As part of our build process we use the technique of deploying tests to a CQ instance that we spin up and invoke the tests remotely - this works fine. However, a complication is that when the CQ quickstart jar is started up it needs license.properties in the working directory. Is there any way we can repackage the quickstart jar with the license.properties so avoid this ? Or can we supply the properties from the license file as command line options or similar ?

Right now copying the license.properties is messy, and every single build needs to have a copy of them available. If we could embed in the jar all builds can simply share it via a private maven repo or similar.

Thanks,

Jon

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

We had the very same issue, and we solved it by repackaging the complete quickstart and injecting a piece of custom code, which copies the license.properties to its expected location and then restarts the license bundle ("com.adobe.granite.license"). It's the not the easiest approach to build this in maven, but it's doable.

View solution in original post

3 Replies

Avatar

Level 10

I would avoid embedding quickstart because one we get from lws is signed jar & making embed makes it unsigned.  I do not have clue about startup parameter. However since you deploying test & will be aware of working directory. Why not just move the file there.  ALternative you can use curl [1] once instance is up and replace id & custname with your values. 

[1]   curl -X POST --user "admin:admin" -d "FormEncoding=utf-8&eula=on&id=x-x&language=en_US&name=custname"  http://localhost:4502/system/granite/license/index.html 

Avatar

Correct answer by
Employee Advisor

We had the very same issue, and we solved it by repackaging the complete quickstart and injecting a piece of custom code, which copies the license.properties to its expected location and then restarts the license bundle ("com.adobe.granite.license"). It's the not the easiest approach to build this in maven, but it's doable.

Avatar

Level 2

Hi Sham,

As I said initially, if we must move the license.properties then every single project we do will need to have a copy of the license.properties in it's source code control. We're using the technique detailed at http://labs.sixdimensions.com/blog/2013-11-26/integration-tests-adobe-cq/. We retrieve the CQ quickstart from a private maven repo, using the standard maven dependency mechanism. If we say have 20 projects going on with CQ then they can all use the same quickstart for the integration tests, but must have a local copy of the license.properties.

 

Jon.