Blade and Gradle Workspace Refresh

Sometimes it is necessary to refresh to update available versions.

So I was starting a new workspace yesterday, issued my normal command:

$ blade init projectname
Error: The command init is missing required parameters.
The following option is required: [-v | --liferay-version] The Liferay product to 
target. Typing "more" will show all product versions.
1: dxp-2024.q1.6
2: dxp-2023.q4.9
3: portal-7.4-ga112
4: dxp-2023.q3.9
5: dxp-7.3-u36
6: dxp-7.3-u35
7: dxp-7.2.8
8: portal-7.3-ga8
9: portal-7.2-ga2

I often go this route to get the list of versions since I have to change targets.

But I was briefly dismayed because I knew for a fact that dxp-2024.q1.7 was available but wasn't in the list.

I needed to refresh the blade list, so I hit a ctrl-c and then used the command:

$ blade init projectname --refresh-releases
Checking for new releases...
Error: The command init is missing required parameters.
The following option is required: [-v | --liferay-version] The Liferay product to 
target. Typing "more" will show all product versions.
1: dxp-2024.q1.7
2: dxp-2023.q4.9
3: portal-7.4-ga112
4: dxp-2023.q3.9
5: dxp-7.3-u36
6: dxp-7.3-u35
7: dxp-7.2.8
8: portal-7.3-ga8
9: portal-7.2-ga2

This extra argument forces Blade to refresh a local file, ~/.liferay/workspaces/release.json which is a local copy of the file from https://releases-cdn.liferay.com/releases.json which contains all of the available releases.

So I picked the 2024 Q1.7 release and my new workspace was ready.

So today I found out that Q1.8 was released. I already had a workspace, so all I needed to do was change my gradle.properties and set the liferay.workspace.product to be dxp-2024.q1.8 and I should have been good to go.

After changing, I did the ./gradlew initBundle command, but it didn't know anything about Q1.8. Again, the local file was cached from yesterday.

To refresh the file, I used a special command, which I'm including below between the before and after listings:

$ head ~/.liferay/workspace/releases.json
[
  {
    "product": "dxp",
    "productGroupVersion": "2024.q1",
    "productVersion": "DXP 2024.Q1.7",
    "promoted": "true",
    "releaseKey": "dxp-2024.q1.7",
    "targetPlatformVersion": "2024.q1.7",
    "url": "https://releases-cdn.liferay.com/dxp/2024.q1.7"
  },
$ gw --stop && gw initBundle -Dliferay.workspace.refresh.liferay.releases
No Gradle daemons are running.
Starting a Gradle Daemon (subsequent builds will be faster)

Deprecated Gradle features were used in this build, making it incompatible with 
Gradle 8.0.

You can use '--warning-mode all' to show the individual deprecation warnings and 
determine if they come from your own scripts or plugins.

BUILD SUCCESSFUL in 54s
3 actionable tasks: 3 executed
$ head ~/.liferay/workspace/releases.json
[
  {
    "product": "dxp",
    "productGroupVersion": "2024.q1",
    "productVersion": "DXP 2024.Q1.8",
    "promoted": "true",
    "releaseKey": "dxp-2024.q1.8",
    "targetPlatformVersion": "2024.q1.8",
    "url": "https://releases-cdn.liferay.com/dxp/2024.q1.8"
  },

Most of the time, and for most of you out there, this isn't really going to be something you have to worry about.

The cached file is only good for 7 days, on the 8th day the tooling will fetch the update automatically.

But in case you run into this yourself, you'll now know how to handle the refresh.

Blogs

Very useful tips . I faced this issue multiple times 

Hi David,

I appreciate your great work and enthusiasm. This is great post that has just motivated me for my next question. We maintain DXP workspace with custom osgi modules for our customers. Since Liferay announced quarter releases, every workspace refresh blocks our CI infrastructure and causes patience loss and financial loss. Our latest issue came with 2024.q2.1 which cuses compileJava gradle task to end up with error message: Could not find com.liferay.portal:release.dxp.api:. Dependency that causes it is regular official dependency: compileOnly group: "com.liferay.portal", name: "release.dxp.api" To clear things up, I created wanila 2024.q2.1 workspace following your steps. I also used latest blade 7.0.0.202406121824 to crete service-builder module group which relies to autogenerated gradle dependency statement: dependencies {         compileOnly group: "com.liferay.portal", name: "release.dxp.api" }

Trying to compile this module group ends up with same error: Could not find com.liferay.portal:release.dxp.api:. I would be very thankful if you could write post that would tackle this area. Is this gradle caching issue? Is it just Liferay's gradle workspace plugin issue or it is just problem in us engineers :0 How we fixed this problem? We re-write dependency into: compileOnly group: "com.liferay.portal", name: "release.dxp.api", version: "default" Honestly, I have no time to digg arround and find out exactly why this helped even version: "default" is not mandatory in this statement. If you or colleagues engineers in Liferay can write about this it would be really helpfull. 

 

Did you find a solution for the "Could not find com.liferay.portal:release.dxp.api" error?

No. For us most of issues I mentioned always happen during Sundays and Mondays especially when updates for quarter releases are expected. We stopped Liferay activities in the week they do new release. It is enough for tools and repositories to sync. 

Sorry I missed this, Igor...

I'm not sure how you are hitting this, but I do know when Liferay does a "release", it actually spans a couple of days. If you are immediately jumping to a new version as soon as the source json file indicates it is available, it could just be a timing issue (trying to use before all artifacts have been released and CDNs are updated, etc).

Alternatively, we have had issues that have this error which have pointed to the Target Platform being set in the gradle.properties file, but not being properly shared such that the version is not available for the gradle compileOnly directive, so when it complains about "could not find", it actually means "it could not find the artifact because it doesn't know the version"...

When these messages come up on the community slack, I usually reach out to the dev tools team and they do something to fix it. A short term solution you can use is to just tack on the ", version: " with the real version (I don't know that I'd use "default" because it is a little ambiguous to me about just what version it might end up with).

When you guys find stuff like this, reach out in the community slack and I'll get it in front of the team so it can get straightened out...