I've come back to project after a long diversion, and upgraded tooling. This means Netbeans 12.5, Java 17, Gradle 7.3… at least allegedly. For some reason, despite setting the Gradle version to 7.3, it appears to build with 7.0.
Per the image below, setting the Gradle version to 7.3 doesn't seem to be picked up. (That is immediately after hitting Apply.) It still tries to build with 7.0. And – for some indeterminate reason – it can't.
Restarts don't help; I can't get the configuration to be picked up. (Searches for reference to similar issues provide 5-year-old answers that are no longer relevant.) I've even tried deleting the 7.0 distribution; to no avail, it comes right back.
Can anyone provide guidance on getting this to work properly?
Netbeans 12.6 fully supports Java 17 and Gradle 7.3. Gonfiguring the Gradle wrapper for 7.3 gets picked up correctly, eliminating all errors I was experiencing.
Don't bother with gradle in Netbeans. It's a horrible, buggy disaster and 12.6 just seems to want to up the ante.
Netbeans does NOT support gradle in a meaningful way for normal users.
You now get complex multi-projects whether you want them or not.
When creating a Java Application you don't get a choice at what the Main class is called. It will be App with app.java and you will like it.
If you try to rename app.java to something useful. It will not change "Class App" to "Class Useful" it will instead change it to "ClassUsefulp". It will not rename the test file and you will be left with several syntax errors that you can have fun cleaning up.
No, you cannot rename the subproject itself. That will continue to be the extremely descriptive and useful "app" subproject. The IDE will not provide you a way to rename that.
There is no meaningful, intuitive way to create/delete/modify subprojects.
If your gradle version is somehow out of sync there is still no useful way to reset/recreate the gradle wrapper other than creating a whole new project and moving your source code over to the new project.
Oh, so you gave in and accepted the multi-project structure. You noticed that if you go through the multi-project creator GUI then you can create multiple subprojects. Yeah, good luck with that. They won't have gradle build.scripts or wrappers. You won't be able to build your awesome creation.
Want to use command line arguments? Forget it. There is no "run" element in the project properties. You cannot create different run configurations.
Want dependencies? Or any other project configuration? It's all manual editing of gradle files. There's no GUI to assist non-gradle-wizards.
Yeah. you can probably work around a lot of this by dropping to a command line shell and editing the gradle scripts/files manually and running gradle commands manually. A) you're going to need to be a gradle wizard, and B) why are you using an IDE in the first place? you've got gradle, you've got vi available. Bathe in the nostalgia because you'll have to anyways.
Do you like the idea of gradle? Do you use Netbeans? Stick with Ant, or Maven if you need external dependencies; you'll thank me later.
General Java question here / a little maven-y also. I downloaded the parent pom from a repository and did a mvn install to get all of the dependencies, but now when I am writing code, specifically in the example below, I might write something like: conn. and expect the proposals to show up, but they are not. Now say I were to a go step further (since I have it in front of me) and say conn.tableOperations(). I would expect theses proposals to show up, but like I said they are not. Here is a pic of what I am talking about if that explanation didnt suffice:
If I were to type String bla; then bla. all of the proposals would show up for that? I know it must / is related to the dependencies but I have never had this problem before. I did a bit of digging and found that maybe a maven clean install with the proper parameters would help, but I have zero clue what they would be. This is what I am referring to in this regard.
Any ideas? Thanks.
I think you are confused about Maven and Eclipse interaction.
I downloaded the parent pom from a repository and did a mvn install to
get all of the dependencies...
That is your first mistake. mvn install is not what you think it is.
You need to start by installing Maven integration in Eclipse.
This is either already available depending on which package solution
you chose, or it is available in the Eclipse marketplace.
Next you need to create a new Maven project in Eclipse.
Lastly you need to specify a dependency on the jar in the m2e
plugin. This will automatically bring in all the necessary
dependencies into your project workspace.
Note the above link has full documentation, including a Getting Started tutorial.
Alright I solved my problem. I couldn't see the proposals because the project I was trying to edit was still inside of the parent project, which wasn't considered a Java project, hence why the Java proposals weren't showing up. I drilled down into the parent project to the project I was trying to edit, right clicked and clicked "Import as project". It keeps the project still under the parent project and edits are made to both, but now the inner project is considered a Java project. Everything works as expected now.
Suppose you are working on a big project, which is run on some application server (let's say Tomcat, but it may be also Jboss, or Jetty, or something else). The project consists of a several wars, while each war contains a lot of jar. The whole thing is built using Maven and it takes a lot of time to build it all.
Now, suppose a developer makes a change in just one module that produces one small jar. To continue working and test the change, the developer needs to replace this jar in the relevant wars and restart server (sometimes it's sufficient to redeploy wars). It's much faster then rebuilding the whole application. I have seen a lot of developers (including myself) creating shell scripts for this task.
However, it could be much nicer, if it could be done automatically using maven. Let's say when running "mvn install" the plugin will also go to some predefined location (e.g. ${tomcat}/webapps) and search for all appearances of myjar.jar and replace them with a new version (We have multiple jars, remember?)
Does anyone know about such a plugin? Or may be about some other tool that can do the same task? Or some better idea how to do it?
Updated: Btw, If I don't find a solution, I'll probably implement it myself. So please let me know if you are interested. I'll need some beta testers :)
Updated: So I created the plugin myself. See http://code.google.com/p/replace-file-plugin/ Any feedback is appreciated.
Check out JRebel. It rocks, reduces development/deployment time a lot. There is a 30 day free trial, so check it out for free. I purchased my own license, it took my company a few weeks to approve purchasing it, and I couldn't wait.
Seriosuly man, it rocks. Read about it, it can do what you want.
Well, any features I asked for in this question, I have implemented myself. See http://code.google.com/p/replace-file-plugin/
I'll appreciate any feedback.
If you can write your script as a Ant build, you can use the Maven Antrun plugin to embed the Ant build in your build lifecycle.
Let's narrow the scope to one and only war file, I think you'd scale this up to your scenario yourself with no trouble.
You may try this option: create a final assembly module which runs fast and combines all dependee modules into one war-file. Then, if you initially do mvn clean package install for the whole build, you'd have to mvn clean package install the changed dependee module and re-run the final assembly module to quickly get grab on the updated war. This is quite stateful build scheme (and thus error prone), but after some getting familiar with this approach to change propagation you'd probably think this is the most simple idea that might work, and work faster.
So I have a maven module (module-A) in IntelliJ. I recently moved some classes from it into another new maven module (module-B) and added a dependency to it. Once I had done this I also modified the signature of a method of one of the moved classes (now in module-B).
I re-imported the poms so that IntelliJ would pick up the dependency changes and ensured all Java imports for the affected files were correct again. Now when I attempt to run my webapp (which depends on the two modules) I get a compile error in a class in module-A calling the modified method of the class in module-B.
The error message is basically saying that that method doesn't exist but believes the old method still exists! I click on the 'make' error and it takes me to the line in a class in module-A calling the modified method...the weird thing is, IntelliJ knows it is fine in the file. i.e. The method is not underlined in red like a compile error would normally be, but the class file name is :(
I compiled it from the command line using 'mvn install' (having also installed module-B) and it is all successful. I have deleted the classes directory in the target of both module-A and module-B and also invalidated IntelliJ's caches and restarted...still happening...any ideas?
I found out that this might help:
File -> Invalidate Caches
Maven Projects -> Reimport should help.
I spent a few hours on this same issue. All of the cleans in the world didn't help.
I deleted my out and target directory in my project and recompiled - that cleared it.
Edit: There is also a magic feature under the file menu: "Invalidate Caches / Restart" This fixes a bunch of "intellij is confused" problems.
Change "Java Compiler" setting in IDEA (User compiler javac in-process) to fix the problem.
Try to mvn clean your projects and mvn install your project B.
The maven integration with intelliJ is kind of buggy when you use the make command directly provided by Intellij. You should directly use the mvn commands, or start them from the maven panel.
I ran across a very similar problem that was driving me insane.
My code would compile fine with the ant task I normally run, but it would not build in IntelliJ, complaining about "Cannot Find Symbol blah blah"
Turns out, you can add "Excluded" files for the compiler. My file somehow got added to that list.
This list is located in File > Settings > Compiler > Excludes (IntelliJ 13)
Following steps should fix this problem :
delete .IntelliJIdea12 / .IdeaIC12 older under c:/user/.../
Invalidate Intelli's cache: File > Invalidate Caches.
This re-indexes your workspace on start-up and also clears your local history. Before you do this, commit or back up all your uncommitted changes.
Once your workspace is back after indexing, do a maven clean install.
when the build is successful, click on Maven Re-imports
This worked for me, I think it should work for others too with a similar problem.
So just stated it up this morning and it's all working!
Last night what I did do was open a new project (intelliJ project) from module-A's and module-B's parent pom and successfully got it to build, possibly doing that and then opening my original project again fixed it somehow...very annoying though
The behavior I see is similar to the one described by the original author.
Error markers show up on the right side of the editor in Intellij 14 and less so in 13.
This happens also if using Scala instead of Java and using SBT instead of Maven.
Also noticed this occurs after the second project is loaded. The first is always fine.
(After much trial and error) Figured it might be caused by Intellij's internal caches becoming somehow corrupt. "Invalidate caches" worked sometime and sometimes did not.
I work with a number of projects using Play! Framework and they use different versions of Scala and lots of dependencies.
I hypothesized the caches become corrupt because the internal key Intellij uses is not good enough to handle situations when the same class, loaded multiple times in different jars, has different signatures, and this results in the editor errors while external builds work fine.
Then the "Changing Ivy Cache Location for sbt projects in IntelliJ IDEA?" post gave the idea to segregate the ivy cache SBT and Intellij use in the hope that the ivy path is part of the internal cache key.
Paul Phillips of TypeSafe provide the "SBT extras" tooling and here I found a way to instruct SBT to use a project based ivy home, cache and SBT boot:
https: //raw.githubusercontent.com/paulp/sbt-extras/master/sbt
declare -r noshare_opts="-Dsbt.global.base=project/.sbtboot -Dsbt.boot.directory=project/.boot -Dsbt.ivy.home=project/.ivy"
How to configure Intellij
: see http://content.screencast.com/users/SemanticBeeng/folders/Snagit/media/ec8ec491-6d0c-4691-9598-916a63ba65ef/12.02.2014-08.59.png
Then did the same for the external SBT build to work in sync
: see http://content.screencast.com/users/SemanticBeeng/folders/Snagit/media/dcb287c4-200f-47f3-a937-42865675a22b/12.02.2014-09.01.png
Finally got rid of the user home based .ivy2 and all the contents.
To be sure Intellij does not use this folder I made it readonly.
This was a mistake. Intellij seems to silently fail resolve dependencies if you do this.
This solved the errors and believe they will not come back. :-)
If Intellij guys hear this: please test your releases (Scala, SBT, editor) with all the Play Framework templates from TypeSafe. The problem becomes apparent quickly this way.
I just had a similar issue that was driving me insane. I had done all the other things mentioned in the answers above because I have used Intellij forever, but none worked. In the end I found out that in the maven projects portion of Intellij, one of my modules had been marked "ignore" a simple unignore command from the context menu did the trick.
In my case, I had manually marked a directory as "Test Sources Root" but IDEA marked it on a parent Maven project. Unmarking it in File->Project structure...->Modules fixed the problem.
This could happen if you are using different version of java while building outside IntelljJ. My IntelliJ had java10 and I was using java8 while building at terminal. Changing java version to IntelliJ fixed this issue for me.
I had a very similar behavior. Running (Scala-)tests would always fail due to errors in unrelated java classes during the 'make' step.
It turned out, I had included a 'global' SDK library that collided with one of the dependencies from the project. A proper helpful error message only showed up after I deleted the 'make' step from the test.
I then deleted the duplicate library, re-added the make step to the test and everything is now working fine.
I ran into this problem today after upgrading from 12 to 13.
Later I fixed issue as I used the same name for Project and Module and looks Intellij allows this but cannot handle it correctly.
No idea why setting will impact the compilation, although there is no error in java editor. Should be a bug in version 13.
I was facing a similar issue after upgrading from IntelliJ 12 to 13. After multiple uninstalls and re-installs (of multiple intelliJ versions), numerous cleans and .m2 repository clearing, I finally figured out what my issue was.
In my intelliJ settings, the repositories mentioned in my main POM file could not be connected to. this was in turn due and alternate repository that was mentioned as a part of my pom file.
Once the POM was made to point to the correct repository, all my classes had their compilation issues resolved.
To check if your repositories are being connected to, go to File -> Settings -> Maven -> Repositories
Here, your indexed maven repositories should be connected to successfully. If they are not, then intelliJ will not be able to resolve most 3rd party and module dependencies.
I'm embarrassed to say, but we also had this problem, but it was due to a mistake in our package name.
When creating the packages for a new project I accidentally created a package called "org.package".
My project then had a directory structure like:
/src/main/java/org.package/
Which caused all sorts of havoc with IntilliJ.
Once the correct folder structure was created on the file system, IntelliJ worked great.
/src/main/java/org/package/
Note the difference in /org.package/ vs /org/package/
The fix was i made it javac instead of Ajc and i put 1.8 of course according to your jdk version.
for some reason when i invalidate and restart intellij it was set to be the default !
my version is
This happened to me...what fixed it was realising there was an extra main.iml file in the source directory. Deleting that instantly made the compile errors go away.
None of the above answers worked for me.
In my case, I had to finally create an explicit Maven Run Configuration for the module (with Command Line as "clean install") and then run it.
It is in Run > Edit Configurations
close the project
go-to the project folder and delete idea project file and .iws file
run mvn idea:idea
restart the project.
seems idea keeping the old project dependencies without cleaning even though we run file -> invalidate caches
Setting the proper Java SDK solves the issue
Right click on the project and select "Open Module Settings"
Check if you have the right Java SDK under platform settings
Check the SDK under Modules
Rebuild the project from "Build" menu
Delete the installation directory.
Remove the following directories:
~/.config/JetBrains/
~/.cache/JetBrains/
~/.local/share/JetBrains/
This will remove each and every configuration plus installation of jetbrains tools, be it IDEA, goland,etc.
Now install everything from scratch.
That's the only way it worked for me
I am new to Hudson, perhaps someone knows the solution:
I am trying to checkout the parent pom from the VSS in Hudson (vss plugin installed) and now I get class cast exception:
FATAL: hudson.maven.MavenModuleSetBuild cannot be cast to hudson.model.Build
java.lang.ClassCastException: hudson.maven.MavenModuleSetBuild cannot be cast to hudson.model.Build
at scm.vss.VSSSCM.checkout(VSSSCM.java:227)
at hudson.model.AbstractProject.checkout(AbstractProject.java:664)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:260)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:234)
at hudson.model.Run.run(Run.java:793)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:205)
at hudson.model.ResourceController.execute(ResourceController.java:70)
at hudson.model.Executor.run(Executor.java:88)
The line in question is here:
Build lastBuild = (Build)build.getPreviousBuild();
Has the interface changed? Anyone knows the solution?
Looks like Shashi filed this as Hudson issue 2665 which remains open.
Looks like it's a bug in that version of Hudson. Have you tried a slightly older or newer version? IIRC they provide very frequent stable builds, almost nightly...
I've never faced that situation, but I have faced other problems when using maven projects in hudson like infinite loops upon builds and so (that I think Hudson itself should evaluate and avoid). By this I mean that this feature is quitely young and error-prone.
Regarding at your exception, I can advise you to configure the project as a freestyle software project. If you set up the "Execute maven top-level targets" option on the build steps, the project will be built using Maven and probably the exception will dissapear.
The other thing that Hudson does automatically when a project is configured as a maven project is triggering builds for dependent project on successfull build, but, you also can configure it manually by using the "Build other projects" feature.
As you see, it's a little configuration price to pay and I strongly think that your exception will dissapear.
Hope it helps.
Carlos