Having trouble compiling my libgdx project to html.
Looking at the log I think the problem is;
Copying resources from ../android/assets to war/
C:\TomsProjects\MeshExplorerV2\html\..\android\assets
C:\TomsProjects\MeshExplorerV2\html\assets
[ERROR] Generator 'com.badlogic.gdx.backends.gwt.preloader.PreloaderBundleGenerator' threw an exception while rebinding 'com.badlogic.gdx.backends.gwt.preloader.PreloaderBundle'
java.lang.RuntimeException: Couldn't clean target path 'war\assets'
Now it strikes me as slightly odd the second line; As there was no html\assets folder.
The assets folder was in html\war\assets, like the last line complains about.
However, after creating a empty assets folder in html, and manually deleting the contents of html\war\assets I still get the same error.
Theres also a "html\webapp" directory without any assets folder. Not sure if there should be one.
I have tried cleaning/rebuilding from eclipse, as well as randomly also trying Gradle>>Refresh All.
Additionally, the Java version runs just fine.
Any pointers, thanks :)
While not exactly reveling the route of the problem, I noticed it let me compile again as long as I restarted eclipse inbetween.
This infers some file-lock going on, possibly a server still running, allthough nothing but the gwt compile as triggered by me.
Still, restarting is a fine workaround for me as it only takes a minute or two.
ah
Pinned it down: Close your FTP program when compiling - at least CoreFTP was locking the directory. Closing it works every time now.
I had a similar issue where I was getting the following error
[ERROR] Generator 'com.badlogic.gdx.backends.gwt.preloader.PreloaderBundleGenerator' threw an exception while rebinding 'com.badlogic.gdx.backends.gwt.preloader.PreloaderBundle'
java.lang.RuntimeException: Couldn't clean target path 'war/assets'
All my files under the html/war/assets directory were read only, re-starting the IDE didn't help. To fix it I needed to change permissions chmod -R 777 html/war/assets (you probably dont need 777).
Related
I'm using the GCE library in Go, along with go modules.
I'm finding that, while it happily compiles and runs unit tests, it's not resolving those types (e.g. compute.Instance) in the Goland IDE. I'm using 2020.2.
I first added this dependency by hand-coding (adding "google.golang.org/api/compute/v1" to my imports, and letting the module handler load whatever it needs). It added google.golang.org/api v0.50.0 to my go.mod file.
I've tried the old "Invalidate and Restart" approach, and it didn't do anything. I have another project where a different version of that module happens to be loaded, and it works fine on that one.
I've even tried a more nuclear version (Invalidate (no restart), close project, close IDE, delete the .idea directory, and delete the contents of ~/.cache/JetBrains). Still no dice.
FWIW my go module's version is go 1.15
You can navigate to the package sources by pressing Command/CTRL+Click on the import statement (or via External Libraries menu in Project View) and find compute-gen.go file and size limit warning. The IDE behaves as expected.
As a workaround, you can invoke Help | Edit Custom Properties... and add the following line idea.max.intellisense.filesize=8500000 (depends on the original file size), restart GoLand. Please, keep in mind that the IDE can be slow when dealing with large files even if they are not open in the editor.
You can read more about the idea.properties file here.
On trying to re-compile all files in a solution, using Visual Studio 2017, I get this uninformative error message:
Web Compiler found an error in compilerconfig.json
To begin with, there is more than one compilerconfig.json file in the solution.
Secondly, there is no indication whatsoever of what the error is, where it occurs (line number, for instance).
Any ideas how I can go about solving this?
In Visual Studio's Solution Explorer, right-click the compilerconfig.json file and click "Task Runner Explorer". In the left pane you will see "compilerconfig.json/all files", right-click on it and then click on "Run". You will see the details of the execution which, in my case, included the useful information about how to correct the error.
I was able to solve this issue for myself by using individual file compiling, instead of "All files".
I was getting a "Compiling successful!" message, but that didn't seem true because my compile file didn't contain my change. So here's what I did:
Open Window > Task Runner Explorer. In your left column, there is a task for "All Files". That's fine. Ignore it.
Compile your SCSS files individually. Do this by right clicking on each SCSS file in that list, and then Bindings > After Build. (Or add the task to whatever event you prefer. I chose After Build.)
Open any SCSS file in your project and add a test. I added something like #TEST2 {color: hotpink;} to my SCSS file.
Now when you save, your compiling takes a few seconds longer. Now open main.css and see if your change (#TEST2) exists in the file.
I just went through this and didn't find an easy way but I got past it.
My issue turns out to be a missing input file that was supposed to be compiled.
Method of attack:
Try to compile each compilerconfig.json file (right-click -> Web Compiler -> re-compile all files)
repeat until you find the file in question
Remove all data from this file and add entries in one at a time (or scan it to make sure your files are there, which ever fits your situation)
The root problem is that the Web Compiler didn't install successfully. I had the same problem as described in the other answers and went down a rabbit hole to figure out why I couldn't compile. Turns out I had to help the tool install itself. See this comment for details:
https://github.com/madskristensen/WebCompiler/issues/390#issuecomment-475427735
Once I did the steps listed in that comment, I able to both compile files again and was explicitly told by the tool which line of my SCSS had an error.
For an information:
I got the same error in VS2019 webcompiler. And I found a solution ie;
Project should be open as a "Web Site".
Do not open as a folder. This simple thing is solved my issue.
I'm trying to setup limeJS, the issue is the Internet connection is a problem. I had closure library, box2d, closure compiler and closure templates downloaded separately as .rar files, but I can't find a guide anywhere to set it up like this, everyone just uses(and with reason!!!) the python bin/lime.py init command to get it working. I managed to figure out(yay!) how to setup box2d and closure library but what about the other two?
My laptop is running 64 bits Windows 7. Any help appreciated
All I need is an advice on directory structure, like where to drop the compiler.jar and soy templates .js files, so that when I run the update/create command it doesn't try to download the compiler or templates like it does right now.
I got it working, after taking a quick look at the lime.py file it told me everything I needed, for example both the SoyJs templates file and the compiler need to be in the /path/to/lime/bin/external folder and for example, the lime.py file was expecting a compiler file named compiler-dateOfLatestCompiler.jar instead of compiler.jar.
In general, If you have LimeJS built up in one machine using Python and all, you can just copy paste the whole package anywhere you want and use it just as ususal.
You don't need network once you have all the files/codes for Lime is downloaded.
Infact, you dont even need python for normal development tasks(Python is required to build your js file once you complete development though)
I am porting over an MSBuild script from CCnet to run in Jenkins. The MSBuild project is used to create a deployment package. I would rather have Jenkins drive this process itself but that's a longer term aim.
The problem i am having is (as in the title) when we try and use the HgPull target, from the MSBuild mecurial task (http://msbuildhg.codeplex.com/) we get the error message
HgProcessException: The command hg.exe is not available [Path to project]
I have seen on the project web site that someone solved it by adding the LibraryLocation proeprty to the target but that seems to have made no difference. My target currently looks like this:
Target Name="UpdateSources">
<HgPull
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Force="true"
Update="true"
LocalPath="$(SourcePath)"
/>
<HgUpdate
LibraryLocation="C:\Program Files\TortoiseHg\hg.exe"
Clean="true"
LocalPath="$(SourcePath)"
/>
I'm rather at a loss. Please let me know if you need any more information added to this post to solve this issue. I'm really quite new to MSBuild so really not sure where to start investigating this.
EDIT:
One thing i forgot to mention was that i have tried running the MSbuild command in a console window on the build server and still get the same result. This is really odd given it works fine in CCNet, what magic is CCNet doing to make this command work?
This is now resolved, unfortunately i'm not sure what changes i made to correct these. I believe it may have been down to path separators and whether they where trailing or not in another part of the config file. It does so annoy me with the lack of resilience/consistency between applications where you need to specify paths with/without trailing slashes.
Just a thought, but try adding 'C:\Program Files\TortoiseHg' to your system path. Maybe CCNet has it specified somewhere that Jenkins doesn't have access to.
Also, just for sanity's sake, verify that hg.exe actually exists at that location.
When I tried repacking all the jars into one jar, and run that one big jar, I got following exception
java.lang.SecurityException: no manifiest section for signature file entry javax/activation/MimeType.class
After googling I found a working solution at
http://www.coderanch.com/t/133070/Security/Jar-File-java-lang-SecurityException
The solution is delete SUN_MICR.RSA and SUN_MICR.SF files from the META-INF folder in the jar. It worked.
I tried to find out
how does this solution work?
. But did not find any answer.
So experts, please help me understand what goes on behind the scene.
Another workaround, which will allow the use of jar building applications without needing some other script, is the following:
•unzip activation.jar (it should be in your classpath since mail.jar needs it)
•open META_INF/MANIFEST.MF
•Copy paste all the lines that look like
Name: javax/activation/MimeTypeParseException.class
SHA1-Digest: uxV3qLHRu5JTOFrHnJXm13AO+0M=
into your program/jar's manifeqt.
Tada ! it works as expected.
Check, there must be another jar file having activation.jar, causing conflict.