search

liferay / liferay-osgi-watch

6 stars 11 forks source link

Watching but not propagating #17

Open ericcoquelin opened 6 years ago

ericcoquelin commented 6 years ago

I am trying the tool unsuccessfully.

I have a very simple Soy project (very similar to the hello soy portlet) and have been working on that project from Eclipse. I use Eclipse only for editing files.

I started my Liferay with default configuration except HTTP port which is 8090. I built the project using gradle build and moved the generated jar to the Liferay deploy folder. My portlet is available and displays correctly.

Then, I started lwatch at the module root folder. It starts and watches without any visible issue.

I updated one of my soy file just to see if it propagates. lwatch catches the modification and perfoms some operations but... it doesn't propagate the modifications to the server.

What is missing?

ericcoquelin commented 6 years ago

Have tried to:

Even running manually the

felix:update <bundleId> reference:file://<explodedDir>

doesn't do anything

brunobasto commented 6 years ago

Hey @ericcoquelin, thanks for reaching out!

Can you paste here the output of the console? Also, what were you using to build/deploy your portlet? gradlew or just the environment gradle?

Do you have your cache properties disabled on portal.properties? Sometimes the JS files get cached and the view doesn't show your changes. I like to always set these:

minifier.enabled=false
javascript.fast.load=false
theme.css.fast.load=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.etag.ETagFilter=false
com.liferay.portal.servlet.filters.header.HeaderFilter=false
com.liferay.portal.servlet.filters.strip.StripFilter=false

To make sure I don't get caching.

brunobasto commented 6 years ago

Even running manually the

felix:update reference:file://

Do you see bundle instalation log on tomcat? This makes me think it may be caching issues.

ericcoquelin commented 6 years ago

Do you see bundle instalation log on tomcat? This makes me think it may be caching issues.

Yes, I have the following showing

14:56:35,981 INFO [Thread-40][BundleStartStopLogger:38] STOPPED com.liferay.demo.telco.dashboard_1.0.0 [575] 14:56:36,358 INFO [Thread-40][BundleStartStopLogger:35] STARTED com.liferay.demo.telco.dashboard_1.0.0 [575]

To install the initial jar, i have run gradle build using Eclipse on my project. Then, I copied the jar to deploy folder.

My Liferay is started from Eclipse using developer mode. I am using Liferay developer studio.

ericcoquelin commented 6 years ago

This is indeed a cache issue but the suggested solution doesn't work.

In order to propagate SOY modifications, I need to:

  1. start the server in developer mode (which includes all communicated parameters and I have added the strip filter in case of)
  2. Deploy the SOY portlet manually in the deploy folder
  3. run lwatch in the root folder of the portlet with default configuration (so no json file)
  4. Edit the View.soy portlet
  5. Reload the page --> Nothing new
  6. felix:update the file (as per above)
  7. Reload the page --> Nothing new
  8. Clean the cache "Clear content cached by this VM." in the control panel
  9. Reload the page --> Modifications are visible

Two conclusions:

  1. With the default conf, the modifications are not propagated anyway
  2. Need to find out why or how deactivate that cache for pages
brunobasto commented 6 years ago

Ok, I think I know what might be happening. Do you have the Provide-Capability header defined on your bnd file like here: https://github.com/liferay/liferay-portal/blob/master/modules/apps/foundation/hello-soy/hello-soy-web/bnd.bnd ?

ericcoquelin commented 6 years ago

I just have

Bundle-Name: telco-dashboard Bundle-SymbolicName: com.liferay.demo.telco.dashboard Bundle-Version: 1.0.0 Require-Capability:\ soy;\ filter:="(type=metal)"

Can you please explain ?

ericcoquelin commented 6 years ago

OK, I have updated with the following

Bundle-Name: telco-dashboard Bundle-SymbolicName: com.liferay.demo.telco.dashboard Bundle-Version: 1.0.0 Require-Capability:\ soy;\ filter:="(type=metal)" Provide-Capability:\ soy;\ type="telco-dashboard";\ version:Version="1.0.0"

Now, it propagates right after the felix update. Still need that step. Is that the expected behavior ? Can you please explain how it impacts ?

brunobasto commented 6 years ago

It shouldn't need that extra step. I think it may be a bug with lwatch.

Just out of curiosity, can you make sure you have your browser caching disabled? And try changing a Soy file and reload the page?

ericcoquelin commented 6 years ago

I have updated the json configuration so that skipInstall=false everywhere.

I have even added it to the java builder but it doesn't propagate. Does it work for Java ?

brunobasto commented 6 years ago

I have updated the json configuration so that skipInstall=false everywhere.

That's what I was thinking to do to make sure we invalidate the server-side cache. Did that not work?

Remember that SoyPortlet renders the views both from the server and the client. So, if your browser somehow cached view.soy.js for example, that might be why you didn't see any changes.

brunobasto commented 6 years ago

I have even added it to the java builder but it doesn't propagate. Does it work for Java ?

What you mean?

ericcoquelin commented 6 years ago

But with all the updated configuration, it works for SOY files.

brunobasto commented 6 years ago

It makes sense that we should not skip install for Soy files because of the caching issue. I'll fix that.

When I modify my portlet class, it doesn't propagate -> modifications are ignored

Do you see the gradle output or get any errors during the class compilation?

ericcoquelin commented 6 years ago

Unfortunately, I can't see any errors. Looks like compilation is successful but class files are not being reloaded

`ecoquelin@ubuntu17-VirtualBox:~/workspaces/demo/telco/modules/telco-dashboard$ lwatch [16:27:43] config Project type set to: osgi [16:27:43] config Resolved config: { "gogoPort": 11311, "notifications": true, "pathExploded": "build/exploded", "builders": { "java": { "glob": "src/main/java//*.java", "config": { "outputGlob": "classes/*/.class" }, "skipInstall": false }, "javascript": { "glob": [ "src/main/resources/META-INF/resources//*.js", "!src/main/resources/META-INF/resources//*.es.js" ], "skipInstall": false, "config": { "outputDir": "META-INF/resources" } }, "javascript-es6": { "glob": [ "src/main/resources/META-INF/resources/*/.es.js", "!src/main/resources/META-INF/resources//*.js" ], "skipInstall": false, "config": {} }, "jsp": { "glob": "src/main/resources/META-INF/resources//*.jsp", "config": {} }, "sass": { "glob": "src/main/resources/META-INF/resources/*/.scss", "skipInstall": false, "config": { "outputDir": "META-INF/resources" } }, "soy": { "glob": "src/main/resources/META-INF/resources//*.soy", "skipInstall": false, "config": {} } }, "ignoreGradleSettings": false, "projectType": "osgi" }

[16:27:44] unjar Unpacking deployed bundle

package.json telco-dashboard@1.0.0 No description package.json telco-dashboard@1.0.0 No repository field. package.json telco-dashboard@1.0.0 No README data package.json telco-dashboard@1.0.0 No license field. [16:27:45] unjar took: 538 ms [16:27:45] build Building entire project [16:27:45] build-java Compiling Java classes [16:27:45] build-javascript Copying Javascript files [16:27:45] build-soy Compiling soy files [16:27:45] build-jsp Copying JSP files [16:27:45] unzip-portal-common-css Extracting portal common CSS [16:27:45] build-javascript took: 35 ms [16:27:45] build-jsp took: 15 ms [16:27:45] unzip-portal-common-css took: 115 ms [16:27:45] build-sass Building CSS files [16:27:45] build-sass took: 4.85 ms [16:27:52] build-soy took: 7.29 s [16:27:52] build-javascript-es6 Transpiling ES6 files [16:27:52] build-javascript-es6 took: 9.16 ms [16:27:53] build-java took: 8.57 s [16:27:53] build took: 8.57 s [16:27:53] install Updating OSGi bundle [16:27:54] install took: 466 ms [16:27:54] startup took: 9.04 s [16:27:54] watch Listening for changes [16:28:41] build-soy Compiling soy files [16:28:42] build-soy took: 1.21 s [16:28:42] install Updating OSGi bundle [16:28:42] install took: 604 ms [16:28:57] build-java Compiling Java classes [16:29:00] build-java took: 3.22 s [16:29:00] install Updating OSGi bundle [16:29:01] install took: 578 ms [16:36:03] build-java Compiling Java classes [16:36:04] build-java took: 1.79 s [16:36:04] install Updating OSGi bundle [16:36:05] install took: 546 ms `

brunobasto commented 6 years ago

Hey @ericcoquelin, to test the issue with the java compilation, can you tell me what version of portal and, if possible, what module you are trying to deploy? I might try it myself here to see if I spot what the problem might be.

ericcoquelin commented 6 years ago

Java is not propagating because the default java configuration is not correct.

It needs to be as below

"java": { "glob": "src/main/java/**/*.java", "config": { "outputGlob": "build/classes/main/**/*.class" }, "skipInstall": false },

brunobasto commented 6 years ago

Hey @ericcoquelin, I think this actually depends on how you are building your modules. I saw that in liferay-portal/modules, classes is a folder outside the build folder.

izaera commented 6 years ago

As @brunobasto says, liferay-portal's build is not "standard", in the sense that blade workspaces output artifacts to the standard gradle folder (build) but the portal doesn't and uses classes directly.

In liferay-npm-bundler I decided to make blade's decission the "standard" and assume that liferay-portal's build is customized. I think we should do the same with the rest of tools or -if for any reason we decide to do the opposite- change liferay-npm-bundler too, so that all out tools do the same.