Watch synapse-react-client & automatically copy resources #5621
Conversation
nickgros
force-pushed
the
watch-src-files
branch
from
89d7edf to
c208eca
Compare
nickgros
force-pushed
the
watch-src-files
branch
from
c208eca to
d82664b
Compare
For some reason, my codeserver would occasionally create incorrect (stale?) .rpc files for DevMode after running `mvn clean compile`. Running `mvn clean package` would somehow fix this. I am hoping that moving the RPC assembly to the `package` step will prevent this from happening. The error in the RPC response would read "Type name elision in RPC payloads is only supported if the RPC whitelist file is used." and the client could not deserialize it. I noticed that the .rpc file names generated by `mvn package` differed from those generated by `mvn compile`, so I am assuming this assembly step accounts for the difference.
| <watch> | ||
| <directory>${project.basedir}/src/main/webapp/css</directory> | ||
| <directory>${project.basedir}/src/main/webapp/sass</directory> | ||
| </watch> |
There was a problem hiding this comment.
Watch source SCSS and CSS files for changes
| <directory> | ||
| ${project.basedir}/node_modules/synapse-react-client/dist/umd | ||
| </directory> |
There was a problem hiding this comment.
Watch synapse-react-client for changes. We can update this list as needed; I didn't want to start with watching the entire node_modules folder (not sure of the performance implications of watching 80k+ files)
| @@ -316,7 +342,7 @@ | |||
| <execution> | |||
| <id>make-assembly</id> | |||
| <!-- this is used for inheritance merges --> | |||
| <phase>package</phase> | |||
| <phase>compile</phase> | |||
There was a problem hiding this comment.
For some reason, my local instance of the GWT servlet would occasionally respond with esoteric failure messages on RPCs. The error in the RPC response would read "Type name elision in RPC payloads is only supported if the RPC whitelist file is used." and the client could not deserialize it. I have been having this issue for ages, with both Tomcat & Jetty, regardless of if I started the code server with the Maven plugin or the IntelliJ GWT extension.
Today I discovered that this was because my code server seemed to create incorrect (stale?) .rpc files for DevMode after running either mvn clean compile or mvn gwt:run. Running mvn clean package somehow fixed this. I noticed that the compiled .rpc file names generated after running mvn package differed from those generated by mvn compile, so I am assuming this assembly step accounts for the difference.
My working theory is that this assembly step is related and maybe updates some stale cache layer? I would appreciate more insight into this step if more context is available. I am hoping that moving the RPC assembly to the compile step will prevent this from happening in general.
There was a problem hiding this comment.
I've also encountered stale rpc files that breaks GWT RPC (with the unable to deserialize client error). I wish I had more context to give, but I don't see any issues moving this to the compile step
|
Those force pushes are a bit scary (are you permanently deleting the correct commits?). I assume you know what you're doing, since I don't remember losing any upstream work (so my assumption is that you are deleting your own local commits). I feel it's our responsibility to raise the cautionary flag for this case, whether it's a real problem or not. |
|
@jay-hodgson I'm only force-pushing over commits that are in my feature branches' history only, so shared history is untouched. Before my code has been reviewed, I'll often overwrite commits if I don't think that the sequence or commit messages provide useful context for anyone that might review the commit log (I especially do a lot of |
No description provided.