I suspect that the way this project is developed by my team is counter-intuitive as far as gradle is concerned, however, that's not about to change any time soon.
Also... technically the location in the drop down menu points towards a missing feature/plugin or error at IDE level.
Any ideas on how to fix this, or where I would begin modding netbeans itself to fix this would be appreciated.
The only options for changing the way packages show up in the project tab, i.e. tree/reducedTree/list etc don't change anything at that level.
I feel I don't have to explain this, but those Business Packages [java][src] entries should show up as something like com.sun.moon.stars packages
Thank you.
at time of writing, 2020/01/18, apache netbeans can't deal with jdk8 codebases defined in gradle.
Solution is to use Netbeans 8.
Related
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.
I am a beginner developer trying to create my first project using Jhipster. I am trying to set up everything to start coding in the most accurate environment in order to avoid further problems or warning in the future.
I have imported the new project to the Eclipse IDE following the instructions in jHipster web, but as you can see in the picture, some warnings appear:
Is there something important that I have to worry about? If yes, how can I solve it?
I can solve the first one, but I am not sure if I solve it in the right way. I did not find any solution related to the other ones.
Is there something important that I have to worry about? If yes, how can I solve it?
Warnings are not high priority problems, they will not break your application. That said fixing them is never a bad idea, I personally like to keep my projects clean.
Most of the Java problems you have are for unused imports or variables, remove them from your code and the warnings will disappear. You can double click on each warning and eclipse will take you right to the line of code.
For the serialVersionUID problems you can just click on the yellow light bulb left of the line number and then click Add default serial version ID.
The first two problems you say you can fix them, good. They are telling you there is a mismatch between the expected Java version and the one used. One way to fix them is to install the 1.8 JDK (get it from here) and set it as your default JRE (Windows > Preferences > Java > Installed JREs).
I have setup a dynamic web project in eclipse with JSF in which I trust on code from another project (framework). Therefore, I added the framework project to the build path of the website project.
So far so good, Eclipse recognises every class and the project builds without errors.
Problem is though that when I do "run on server" to test it on tomcat 6.0.24, the application fails. I get ClassNotFoundException on every class from the framework project.
Is this a bug or is some specific configuration necessary for this?
I was googling and ended up here for a similar problem. I wanted to make a note for others about the current situation on Eclipse Indigo, as the terminology has changed a bit by the looks of things.
On your project properties, do a filter/search for "deployment assembly".
It is then straightforward to add a project dependency. Job Done.
Thanks to Alexander's edited answer which led me to this.
Did you check Warnings in Problems view?
Do you see Classpath entry /your/framework.jar will not be exported or published. Runtime ClassNotFoundExceptions may result warning?
If you do.
Right-Click the warning and choose Quick Fix.
Choose "Mark the associated entry as publish/export dependency." from Select a Fix box.
Click Finish.
EDIT
Now, I think I understand where disconnect is. I think now I remember the joy of figuring this out for the first time.
In your website project ( I will speculate here , but I guess you've created it as a Dynamic Web Project ):
Open project properties
Select Java EE Module Dependencies panel
Check your framework project in JAR/Module column. Beware, that for reasons not known to me, the list is not sorted ( and is not sortable ) in any particular order, so you may need to search for your project reference there.
The results of this operation will be written to /website-project/.settings/org.eclipse.wst.common.component file. Put this file into your source control.
I'm coming from the .NET world where Visual Studio is pretty ubiquitous. VS has a .sln file which pretty exhaustively describes a project, including where to find source files, dependencies, etc.
Now I'm doing some java coding in a team. My problem is this: I'm using intellij and others are using eclipse (while others could be using some other IDE). Is there a standard project description file that can be shared among IDE's? I obviously don't want to put my intellij specific files to source control. So what I'm looking for is a standard that pretty much any self-respecting IDE would recognize which you could point it to and it would be able to interpret the project structure, how to find dependencies, the class paths, etc.
Maven should be able to do it (a project build manager and source control overlay), but alas, there is no standard project file. There are Maven plug-ins available for all the major IDEs. http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
Note quite. But you have a "way out". You can use Maven2. It has a unified pom file which contains all:
source folders (note: maven imposes a default convention on those, but they are still configurable)
compiler level
dependencies
build steps
etc..
(Of course that would require to install the maven plugins for both IDEs)
Another option would be to force either of the IDEs and commit their proprietary descriptors.
As others have posted, Ant and Maven are pretty much the de facto project spec utilities in the Java world. Those are both generally easy to learn -- a fair learning curve, but nothing dramatic -- and are pretty powerful. You could speak to your team members or leader and see how they've dealt with it -- I'm sure it isn't a new problem.
Aside from that, a lot of development teams (in my experience, at least) try to avoid putting project files in source control. The developers are required to basically create their own projects in whatever IDE they're using. It makes getting started on a project a little more difficult for a developer coming fresh into an existing project, but it also helps the developer get a little better acquainted with the project.
At my shop (very, very small team), we use Eclipse, but we still have to manage the workspaces (similar to VS solutions, but not quite the same) ourselves. I've created some Ant scripts for use on our continuous integration server, and that won't necessarily keep problems from arising, but it helps make them more obvious when they do.
There is no such standard project description file as far as I know. But intellij is able to take an eclipse and convert to an intellij project. Also you could look at maven.
There is not one. You could switch to an build system using ANT (similar to Make) but that has pitfalls of it's own. You will get the most mileage if you and your team standardize on an IDE though ...
I think what you want here is for a developer using Eclipse to edit the project settings and have those changes reflected in IDEA for some other developer. If that's the case, then Maven is what you want. IDEA 9.x has great support for Maven, and so does Eclipse. If a developer that uses Eclipse edits the dependencies in the Maven project files (pom.xml files), then IDEA can import the files and change it's project settings.
RE: ANT vs Maven - In this respect (syncing project settings) ANT build files won't work because they are imperative (script-like) rather than declarative.
Maven should be the preferred way but most IDE's now days support some kind of ant based project which is what most of the IDES use internally. Usually called free-form projects.
I'm not a Maven fan myself. I'd recommend Ant long before Maven.
If you're using IntelliJ, I'd argue that it does have a pretty standard idiom. And since it can import any Eclipse project file, you'll be on safe turf laying things out as IntelliJ does it.
I don't check in my IntelliJ project files, but the /src, /lib, /test, /resources etc. are all fair game.
The true answer should be that your team should huddle up and come up with a standard layout that you agree on regardless of IDE. You've got to check code into SVN sometime.
Your question is interesting to me, because I'm trying to go in the other direction (Java->C#, IntelliJ->Visual Studio), and I'm having trouble doing the mapping in the other direction.
I think it's just part of learning a language and its native IDE. I find that it's best to find an experienced guide.
One problem you'll have is that the .NET universe is isotropic (all things Microsoft), where even your small corner of the Java universe is heterogeneous (IntelliJ and Eclipse and NetBeans). You're less likely to find one true answer for all of Java.
I am working on a soucre code which was developed using java 1.4 but now we want to migrate it to java 6. I was able to compile it but there are tons of warnings related to use of java generics wherever we have made use of collections framework. It is possible to remove them by manually make changes to them, but I wanna know if is there any tool which can run on the source code and remove all the warnings by making necessary changes ot the code. Any help will be highly appreciated.
Cheers,
Nitin Ware
Eclipse has an option to try to infer the type arguments for generic types. It's not fool-proof, but it's a start. It's available from the "Refactor" option in the context menu when you right-click inside the class's code.
Open your code with Eclipse, select your Package or Project and in the Refactor menu select "Infer Generic Type Arguments". It will infer the types and correctly change almost all the warnings. Correct the last ones by hand.
Unfortunately sometimes the plugin sometimes crash while trying to do it. I'd also try to do it with IntelliJ IDE. Edit: I've tried with InteliJ and it also failed. Nothing happened after 2 days running. The newer eclipse almost worked, just crashed in 2 files. I'm using it in a very old project with non-standard paths. Maybe you'll have better luck.
You could suppress warnings as a compiler option
-nowarn or -Xlint:none
see http://java.sun.com/javase/6/docs/technotes/tools/solaris/javac.html#options
In eclipse you can set the "Target" JVM to 1.4, that should fix your problem in the editor. I think you can also specify a target option to javac, but I'm not sure about that.