Develop Reference

Java category missing in Apache Netbeans

So I installed Apache Netbeans. Installed some of the plugins and instead of just seeing the Java folder in the categories when I want to create a new Project, I see this:
What is Gradle, Ant, and Maven? I am not familiar with Java and wanted to study the language, but I have no idea of what these are.
I keep seeing that I need to have certain plug ins installed and active.
Here they are.

Ant, Maven and Gradle are Java build tools. You don't really need to know the exact differences though.
Java with Ant
The "Java with Ant" option uses NetBeans' own internal project format (based on Ant). In older NetBeans versions this category was simply called "Java"
If you don't need to share your project with non-NetBeans users, use that option.
You will have to manage dependent libraries yourself (download, add them to the project) unless you are only using libraries and frameworks that are bundled with NetBeans. The turnaround times (the time it takes between you hit "Run" and the application actually starts) are the shortest with this option, as Maven and Gradle add substantial overhead to that.
Java with Maven
Maven is a standardized dependency and build management tool. A project defined with Maven can be used by everybody else as it automatically manages (and downloads) any dependency.
Use that option if you know you need to share your project with other people (e.g. hand it in your school or university).
Java with Gradle
Gradle is yet another build tool, which also manages dependencies for your and has more flexibility than Maven. However the build scripts are less standardized than in Maven. But that is also a good option if you know that you need to share your project with other people.
Unless you are using NetBeans 11.1 (which is currently in Beta) I would not use this option as Gradle support in older versions is not as good as Ant or Maven support.
You might want to go through the tutorials on the NetBeans homepage:
http://netbeans.apache.org/help/index.html

How to share code between Eclipse Swing/maven and Androidstudio / gradle project?

I am an experienced Java developer with years of familarity with Eclipse and Maven.
My goal is to create an android application and I am getting familiar with the latest Development environment Android Studio 2.3.2 which obviously uses Java 8 and Gradle. The app shall share code with an Eclipse based project that uses maven and Swing and is also Java 8 based. I am intending to publish the result as an open source project on github.
I found e.g.
https://github.com/uhafner/android-config as an example but that seems to be outdated.
https://github.com/cgeo/cgeo - which explictly states that eclipse is only used for codewriting/testing
Gradle project for plain Java and Android with single source tree suggests an answer for a gradle only approach that has a tutorial link as an answer (which is not accepted) and no example
https://github.com/javadev/calc which is purely maven driven and has two pom.xml files
https://github.com/adrian/upm-swing and https://github.com/adrian/upm-android simply have copied subdirectories instead of any kind of shared config management
How feasible is a combined maven/gradle project structure?
What would be a proper way to structure the project files to accomplish the above goals?
What are good examples projects that follow a similar approach?
My reason to be reluctant with Gradle and IntelliJ is obvious. It is an unfamiliar environment for me and android is not the main target of my development.

Part of the answer seems be covered at:
Can Android Studio be used to run standard Java projects?
I got somewhat of a success with the project https://github.com/BITPlan/can4eve
but would appreciate some help on the android studio / gradle side of things.
The project also has travis support built in and I am also running nightly Jenkins checks based on maven.

Is there a way to open *.pbxproj files with eclipse?

I'm looking (if it exists) a way to import few XCode java projects into eclipse, maybe a plugin or something that starting from a pbxproj file, generates an eclipse project (.classpath + .project).

After many searches on the internet I reached this URI:
Migrating from XCode to eclipse.
There you can read this:
Migrating with a script is pretty easy and it is not a complex script, it just copies files and puts Java classes into the package structure. The script does not do everything, it just takes the drudgery out of it. You will want to convert all the frameworks before the applications as the applications will need the frameworks to build.
The first step is to create a new Eclipse project, a Wonder Application or a Wonder Framework, and give it the same name as the Xcode project. This does NOT mean you will be using Project Wonder, it just refers to a project layout developed for Wonder.
cd into your Xcode project, Run ./fleeto /path/to/eclipse/project, Refresh the project in Eclipse (select and press F5 or use the context menu), Repeat for other frameworks and applications.
For working in Eclipse you will want to have the framework projects included as required projects in the applications and frameworks that use them. For each project, Properties - Java Build Path is the central place to manage your project. Select the Projects tab and add the framework projects that this application references.
These project dependencies work in Eclipse but not for deployment. For deployment you need to reference frameworks from their installed location. Install the framework (see Install on the context menu).
Then go to the Properties - Java Build Path - Libraries tab and configure the WO Frameworks library. Expand the nodes and select the installed framework(s).
REMOVE the checkmarks beside the ERJars and ERExtensions framework if you are not using Project Wonder. Finally, adjust the order on the Order and Export tab so that required projects appear before the WO Frameworks Library. Doing this ensures that Eclipse uses the current code and not a previously installed version.

Is it advisable to have 2 web modules in a single IntelliJ project?

I created an IntelliJ (9) project, and it started off as a single maven pom.xml project.
This project is a spring mvc web application.
I now realize it will be better to actually have 2 spring mvc applications.
Since I use maven now to build and run the application (using the jetty plugin), should I create the 2nd spring mvc application in the same project?
If so, I guess I have to re-work the folders so it is like:
myapp-models/
myapp-spring1/
myapp-spring2/
So this way each spring app will have:
/src/java/main/webapp (or whatever it is, I used a simple web arch type)
Does this make sense?
Do I even bother setting things up in IntelliJ to build using the IDE? (using modules I think?)
Can I still build and run using intelliJ?
BTW, when browsing folders in IntelliJ, it is annoying to keep clicking through the first 3 folders since they are empty, is there a faster way?

This setup is just fine. You may choose which artifacts you want to deploy on Jetty. myapp-spring1 or myapp-spring2 or both. (Maybe artifacts were introduced after IntelliJ IDEA 9.)
BTW: I usually use "View as Package" in the Project tab. There you can select "Compact empty middle packages". At least in IntelliJ 10/11, but Im sure there is something similar in version 9.

You are correct in using multiple modules in Intellij. I create multi module projects all the time.

Best way to automatically check out and compile Eclipse projects with Ant in Hudson or another CI tool?

We have several products which have a lot of shared code and which must be maintained several versions back.
To handle this we use a lot of Eclipse projects, some contain library jars, and some contain shared source code (in several projects to avoid getting a giant heap with numerous dependencies while being able to compile everything from scratch to ensure that source and binaries are consistent). We manage those with projectSet.psf's as these can directly pull all projects out from CVS and leave a fully prepared workspace. We do not do ant builds directly or use maven.
We now want to be able to put all these projects and their various versions in a Continous Integration tool - I like Hudson but this is just a matter of taste - which essentially means that we need to get an automatic way to check out the projects to a fresh workspace, and compile the source folders as described in the project-files in each project. Hudson does not provide such an approach to build a project, so I have been considering what the best way to approach this would be.
Ideas have been
Find or write an ant plugin/converter that understands projectSet.psf's and map to cvs-checkout and compile tags.
Create the build.xml files from within Eclipse and use those. I tried this, and found the result to be verbose and with absolute locations which is not good with automatic tools putting files where they want to.
Write a Hudson plugin which understands projectSet.psf's to derive a configuration and build it.
Just bite the bullet and manually create and update the CI configuration whenever stuff breaks - I don't like this :)
I'd really like to hear about other peoples experiences so I can decide how to approach this.
Edit: Another option might be using a CI which knows better about Eclipse projects and/or project sets. We are not religious - this is just a matter of getting stuff running without having to do everything ourselves. Would Cruise Control be a better option perhaps? Others?
Edit: Found that ant4eclipse has a "Team Project Set" facility. http://ant4eclipse.sourceforge.net/
Edit: Used the ant4eclipse and ant-contrib ant extensions to build a complete workspace as a sjgned runnable jar file similar to the Runnable Jar facility in Eclipse 3.5M6. I am still depending on Eclipse to create the initial empty workspace, and extract the ProjectSet, so that is the next hurdle.
Edit: Ended up with a dual configuration, namely that Hudson extracts the same set of modules as listed in the ProjectSet.pdf file from CVS (which needs to have the same tag) causing them to be located next to each other. Then ant4eclipse works well with the projectSet.psf file embedded in the main module. Caveat: Module list in Hudson must be manually updated, and it appears that a manual workspace cleanup is needed afterwards to let Hudson "discover" that there is more projects now than earlier. This has now worked well for us for a couple of months, but it was quite tedious to get everything working inside the ant file.
Edit: The "Use Team Projects" with ant4eclipse and a Ctrl-A, Ctrl-C in Project Panel with a Ctrl-V in the CVS projects in Hudson has turned out to work well enough for us to live with (for mature projects this is very rarely changed). I am awaiting the release of ant4eclipse 1.0 - http://www.ant4eclipse.org/, currently in milestone 2 - to see how much homegrown functionality can be replaced with ant4eclipse things.
Edit: ant4eclipse is as of 20100609 in M4 so the schedule at http://www.ant4eclipse.org/node?page=1 is slipping somewhat.
Edit: My conclusion after using our ant4eclipse approach for a longer period is that the build script get very gnarly and is hard to maintain. Also the Team ProjectSet facility (which ant4eclipse use to locate the projects) which works well for CVS based repositories, but not after we migrated to git (which is a big thing in itself). New projects will most likely be based on maven, as this has good support in Jenkins.

I'm not completely sure I understand the problem, but it sounds like the root issue is that you have many projects, some of which are dependent on others. Some of the projects that are closer to the "leaf" of the dependency tree need to be able to use "stable" (or previously "released") versions of the more "core" projects.
I solve exactly this problem using Hudson, ant, and ivy. I follow a pattern demonstrated by Clark in Pragmatic Project Automation (he doesn't demonstrate the dependency problems and solutions, and he uses CruiseControl rather than hudson.)
I have a hand-written ant build file (we call it "cc-build.xml", because of our CruiseControl roots.) This file is responsible for refreshing the working space for the project from the CM repository and labeling the contents for future reference. It then hands off control to another hand-written ant build file (build.xml) that is provided by each project's developers. This project is responsible for the traditional build steps (compile, packaging, etc.) It is required to spit out the installable artifacts, unit test reports, etc, to the Hudson artifacts directory. It is my experience that automatically generated build files (by Eclipse or other similar IDE's) will never get close to getting this sufficiently robust for use in a CI scenario.
Additionally, it uses ivy to resolve its own dependencies. Ivy supports precisely-specified dependency versions (e.g. "use version 1.1") and it supports "fuzzy versions" (e.g. "use version 1.1+" or "use the latest version in integration status.") Our projects typically start out specifying a very "fuzzy" version for internal projects under ongoing development, and as they get close to a release point, they "freeze" the dependency version so that stuff stops moving underneath them.
The non-leaf projects (projects that are dependents for other projects) also use ivy to publish their artifacts to our internal ivy repository. That repository keeps all past builds of the dependents, so that any project can always depend on any other previous version.
Lastly, each project in Hudson is configured to have a build trigger that causes a rebuild when any of its dependent projects successfully build. This causes them to get built again with the (possibly) new ivy dependent version.
It is worth noting that once you get this up and running, consistent automated "labeling" or "tagging" of an automated build's inputs is going to be critical for you - otherwise troubleshooting post-build problems is going to result in having to untangle a hornet's nest to find the original source.
Getting all of this setup for our environment took quite a bit of effort (primarily in setting up the ivy repository and ant build files,) but it has paid for itself many times over in saved headaches in manually managing the dependencies and decreased troubleshooting effort.

Write a Hudson plugin which
understands projectSet.psf's to derive
a configuration and build it.
That seems like the winning answer to me.
I work with CruiseControl rather than Hudson but in my experience if you can create a plugin that solves your problem it will quickly payoff. And it is generally pretty easy to write a plugin that is custom fit for your solution as opposed to one that needs to work for everyone in a similar situation.

I have tried both Cruise Control (CC) and Hudson for our CI solution. We (as a company) decided on Hudson. But for your question "Does CC support Eclipse project build" the answer is no as far as I know. CC supports many more different build tools and Source Control systems but it is a bit more difficult to configure and use. As for Hudson, it is more simple to configure and use it. We developed our custom plugins for both CC and Hudson for the parts of our build cycle that they do not provide as is. As for plugin development, if you know / use Maven, Hudson is simpler too. But if you are not familiar to Maven, first you need to learn the basic usage of maven to successfully develop a Hudson plugin. But once you understand the basic usage of maven, plugin development, test and even debug is simpler in Hudson.
For your specific problem, I can think of a solution that makes use of Eclipse plugins as well. You can develop your own Eclipse plugin that for instance gets the psf files from a (configurable) folder, and use Eclipse internals to process these psf's. I mean you can use existing Eclipse source codes that takes a psf file, check-outs it's project definitions and compile these projects. This Eclipse plugin of yours may have a preference page (which you can access by Eclipse -> Window -> Preferences) and configure which folder it will use to look for psf files. Your Eclipse plugin should also have a way to start psf processing without user interaction. For this, you can use ipc to trigger your process. I mean your Eclipse plugin can listen for a port, and you can write another java application that will connect to your plugin through this port and trigger its process. As for CI part, you can use either CC or Hudson and use their external process execution support. If you are using Windows, you can write a bat file (for Linux sh file) that first launchs Eclipse that has your plugin installed. Then it launches your java application that will communicate with your Eclipse plugin to trigger your process. From your CI tool you will need to run your bat / sh file to trigger your process.