I have a maven project on eclipse with jrebel plugin installed. Hot-deploy used to work perfectly last week but now only xhtml pages are hot-deploy. When a java class is changed it doesn't hot deploy.
What I noticed is when I changed a file and save eclipse will automatically build it. But the output folder file is not updated base on file stamp that's why jrebel doesn't pick it up. When I run maven-install it compiles everything and all the java classes are reloaded which is not efficient.
So the main problem is eclipse newly compiled classes don't go to output folder (project/target/classes), even though it's set in Build Path.
Any idea?
By default, the content of your local Maven repository is cached for a day. This can happen even for bad downloads (as I experienced). See https://stackoverflow.com/a/7421893/44089 for a short description of how to work around that.
After several minutes of testing, I found a warning on a jar file specifically guava being downloaded as dependency. I've delete in repo to be redownloaded and after that jrebel is working again.
So the problem is a corrupted jar that causes everything to be rebuild even if only a single file is changed. But the weird part is there's no corrupted file error.
Related
this problem has started after I fixed my Plugin in the maven file with erasing this.
<outputDirectory>D:\My New Plugins\Server\plugins</outputDirectory>
this breaked my first test Server erasing all the Plugin Folder Files and damaged the code. Then after reopening the server, the server always stops at this part:
Which I was worried considering my Plugin is broken. Do I have to make a new Plugin and transfer most of the files?
Note: the Last Yellow Lines in the picture Indicate the Use of the JScoreboard dependency used in my plugin. Thanks.
Edit: There is also a warning in the build log:
maven-shade-plugin has detected that some class files are
present in two or more JARs. When this happens, only one
single version of the class is copied to the uber jar.
Usually this is not harmful and you can skip these warnings,
otherwise try to manually exclude artifacts based on
mvn dependency:tree -Ddetail=true and the above output.
See http://maven.apache.org/plugins/maven-shade-plugin/
This might be Related.
The problem appears to be JScoreBoards. It does not support Minecraft version 1.18, and therefore is unable to load up properly.
Background
I am working on a simple plugin, and have already deployed to the Plugin Repository once before (successfully).
Since my last successful deployment, I found that I had a lot of issues with the IDE. After completely upgrading, and modifying my plugin's directory structure, I have been able to get the plugin to Run again.
Issue
tl;dr - I have an updated plugin in the JetBrain's Plugin Repository that does not work as intended, and I cannot update it correctly!
When I run the plugin, a second instance of the IDE comes up with my plugin working correctly. I edit my code and run the plugin again - the plugin runs smoothly and the updates are applied!!
With all of this, I decided to deploy my updated plugin to the Repository again. Once that was done, I decided to download the plugin and try it out myself; just to make sure things worked.
The issue is that nothing can be found in the plugin file!! Just the updated plugin.xml file and Manifest.mf file. The total size of the archive file is around 500bytes. I know a correct archive would have more files in it, and in my case, the file size should be around 6kb (based on my first successful archive file).
So how can my local IDE instance find the files correctly, but the deployment feature cannot? How does the deployment feature actually work? I get the feeling I have the structure wrong, eventhough the new IDE instance works perfectly
Plugin
GitHub
JetBrain's Plugin Repository
When you install the plugin, the version is shown as v1.1; however, that is not true, in reality. One of the easiest features to determine the actual version of the plugin is the Folded Text foreground color.
v1.0 - RED
v1.1 - YELLOW
Deployment
Preparing Plugin Module for Deployment + resulting plugin.jar file
Contents of plugin.jar
It seems possible that because of the restructuring an old ChroMATERIAL.xml file was left somewhere in the build output. Somehow this could end up in the plugin jar. An invocation of Build > Rebuild Project should fix this problem.
There could also be problems in the project or module configuration, but the project files are not included in the GitHub repository, so that cannot be checked.
My problem is resolved but I don't understand why it wasn't working.
Using: Grails 2.4.2, Groovy 2.3.7, Java 1.7, Eclipse- Indigo
I set my project up, and in the assets folder under grails-app I placed my static assets. I was also using twitter-bootstrap. The project would run, but nothing would be displayed from the assets folder. I did a Grails clean and got build path errors. in Eclipse right clicking the project name and going to Java Build Path and under the source tab there were links such as:
projectName/.link_to_grails_plugins/cache-1.1.7/src/java
or
projectName/.link_to_grails_plugin/asset-pipeline-1.8.11/grails-app/controllers etc
I deleted my target directory, and deleted all the links that were errors inside the Source tab. I restarted eclipse and refreshed, and voila it worked. The links came back, looked exactly the same but were now good apparently. I'm just not 100% sure why it worked though. The assets were in the right place, and never moved. Why did this work?
Eclipse doesn't parse BuildConfig.groovy or infer paths or dependencies - it gets all of that from Grails. You can force it to reconfigure the classpath by right-clicking on the project node in the tree on the left and selecting Grails Tools | Refresh Dependencies. That will cause Eclipse to run grails compile --non-interactive --refresh-dependencies and it gets classpath information from that.
When you restarted it must have determined that enough had been deleted that it needed to refresh itself, or it might just do that each time you restart.
Introduction
I have spend a lot of time to fix this bug
In our application we have a lot of generated code by cxf and jaxb which produces tons of warnings. We use the maven-build-helper plugin to add this code to our projects automatically.
By adding this enhancement, eclipse JDT enabled the possibility to set the javac -nowarn flag for specific source folders. Unluckily, by updating the maven project the flag gets lost. There are a few threads on SO where users got bugged by bug.
What I have tried so far
So i came up with a clever solution, javac has a nowarn flag. I set it to my maven-compiler-plugin and specified the directory. My maven build was fine, but my eclipse build wasn't. My research told me, that eclipse jdt does only use the maven-compiler-plugin source and target version. So my next step was to try to configure the EclipseCompiler, but this is not possible, because there is no possibility to add custom compiler Arguments in eclipse JDT.
Next Step. Inside of the .classpath file, eclipse JDT adds an ignore_optional_problems attribute for each ignored path. By updating the maven project inside of eclipse, this entry gets lost. So i started to write a maven "ignore-source-folder" plugin which should add the missing attribute. To run the plugin each time eclipse starts a build, i also created a m2e connector to refresh the .classpath file and everything should be fine.
By testing my plugin with my connector i realized, it works, but only 70% of the repetitions.
What happened?
Every time eclipse m2e/Jdt starts a new build, all classpath entries will be removed and populated again. When my maven plugin gets triggered by eclipse, a race condition starts.
So I started to analyze the code of jdt and m2e jdt. The ignore_optional_problems flag gets only once set manually inside of the patch which was provided to JDT and isn't stored somewhere else. By triggering a new build via m2e-jdt this information gets lost.
How to fix this problem
To fix this problem, some element has to be added or extended in jdt which contains all ignored folders. If a new build gets triggered and the classpath file gets newly generated by m2e-jdt this element should be checked for ignored paths. ClasspathEntryDescriptor seems to be a good place for it.
My problem
I checked out jdt and m2e jdt, but i have tons of errors inside of my IDE and i have no idea how to start. And even if I fix the code, I have no idea how to build and test it. I think my effort will be to high and we talk about 20 or 30 simple lines of code.
I am afraid if I add my results to the filed bug at eclipse, no one will care about it.
So, is there any developer able and willing to help me for this tiny job?
You need to "fix" the M2E's JDT project configurator. Probably somewhere in the m2e-core project. So, your change should obtain some kind of configuration flag from the project pom and create corresponding classpath entries for JDT.
Occasionally I see eclipse lose the reference to the third party jars contained in the a projects. (you get the the build path error stating the jar cannot be found)
Its easy enough to fix as you can remove the jar, save the properties of the project and then go in and re-add the jar that it could not find, eclipse can then see the path to the jar and you can then compile again.
the problem is that if you have a lot of projects in your build you would have to do this task a lot.
Is there anything you can do to force eclipse to recognise that it actually has the jar on its classpath?
I have also faced the similar situation many times with my projects in eclipse. The jar file path is correct in the .classpath file and the jar is present still eclipse do that. To fix it you open the .classpath file and resave it and refresh the probject in eclipse and it builds fine.
That's a weird behaviour...
If that's ok you can use Maven 2 for your projects. This means that you have to follow Maven's project structure, which is quite ok, but it can be a pain if you decide to migrate old projects.
Then you can run mvn eclipse:eclipse whenever you want and that will fix your problem in a few seconds.