Develop Reference

Java add .jar files automatically as a a Library

I am creating a java project in IntelliJ (without maven or grandle). The project uses an external library, whose .jar file I’ve put into a /lib directory. After that I had to select at the /lib folder “add as library” to use it.
Now I want to push the project to GitHub, so that some people (who are using IntelliJ as well, but in different versions) can use the project.
Now my question:
Is there a way, that they do not have to do the step “add as a library” themselves?
My first idea was to push also some parts of the .idea folder to GitHub, but I am not sure which ones to push and if that could actually work (especially with different versions of IntelliJ).
Do you have any idea how to solve this issue?

If you are using only IntelliJ for building the project, then yes, you should push the .iml files from the .idea folder (or where they happen to be), since they contain the dependencies configured in IntelliJ.
Note, that projects with multiple contributors typically use a build tool like Maven or Gradle.
This is a special build requirement, which I would use Gradle for. With Gradle you can look up a given folder, like /lib and use all .jar files as dependency.
See Gradle example about exactly what you want.
IntelliJ is handy when you do something simple mostly for learning, but if you want to be a professional one day I highly suggest looking into Gradle. It has a learning curve for sure, but you can achieve such simple tasks like this in your question relatively simply. And as you seem to know, pushing .idea to the repository is really not the nicest thing one can do :)
Just a small additional note: Gradle solves the "different version" problem by including a "Gradle wrapper" inside the repository, so everyone cloning the repository will have the same copy of Gradle as well, so the same build process is guaranteed for all contributors.
Also, when I started programming I downloaded the dependencies and used them as jars. But if you learn at least Maven, and your dependency is uploaded to a repository like Maven Central, you can just paste a line of code into your pom.xml (Maven) or build.gradle (Gradle) and you are good to go :)

IntelliJ project where each module has it's own git repository

I am a new IntelliJ user (I've used Eclipse for many years). I'm having a hard time wrapping my head around the-project-is-a-module concept in IntelliJ, since this does not hold true in Eclipse. The main issue I'm having is that I am using my top level package as the project in IntelliJ. I would like this top level package to be in a git repo. I would also like all the dependencies of this package to be in their own respetive git repos. When I check these packages out into my project, a do git status on the top level package, all of the dependencies show up in the untracked files. This behavior seems incorrect to me. How can I fix it?
Thanks!
Edit:
To summarize the clarifications in the comments:
I would like to support hundreds of libraries any of which could change at a time. The dependency graph will also be frequently changing. For this reason, having one git repo or constantly updating .gitignore files is not maintainable.
Currently, I'm using Maven to manage dependencies but I'm open to using whatever is best suited for this job.
Finally, I would like to check out any library into my workspace and modify it and, if possible, have Intellij reflect my local changes when running code as if my local code were already built into the dependency graph. A type of local override if you will.

IntelliJ's directory structure places all of the modules in their parent project's directory. If you are developing libraries which are shared between several other projects, importing the library as a module is probably not the correct solution. Instead, you should treat each library as its own independent project and make "releases" using a build tool such as gradle or maven. Then your projects can treat the libraries the same way they do third-party libraries and use the build tool to import the library.

How can one both be able to use IntelliJ to manage a project's configuration and yet also have a VCS repository with none of IntelliJ's metadata?

I have two things that I want to do that seem like they are in conflict with each other. On the one hand, I would like to use IntelliJ's GUI interface to manage my project's configuration and so I would like to put the metadata in its version-controlled repository. On the other hand, I want the result of my work to be a repository that does not require the end-user to have IntelliJ, so I not only want there to be no metadata in the repository I publish, but in its place I want to have files that provide some standard Java build system in their place. Is there a convenient way to let me have both of these things?

IntelliJ lets you use tools like Ant or Maven for its builds, and provides a nice GUI for interfacing with them. And anyone without the tool can just use Ant or Maven to run the builds from the command line. You'll either have a build.xml (for Ant) or a pom.xml (for Maven) as part of your source tree.
If you're not going to check in the Intellij project configuration, I recommend setting up a configuration-directory-based project then just set up your version control to ignore the .idea directory. Personally, I consider my project configuration to practically be source code, so I tend to check in everything except my .idea/workspace.xml file. As long as I'm using Ant or Maven to do the builds, people without IntelliJ can still build the project fine.

Migrating complex project from Ant to Maven - How to handle unusual folder structures?

In my new project I am confronted with a complex infrastructure with several modules which have grown over the years in an unpleasant, uncontrolled way.
To come to the point: The build process is the horror. There are over 40 different, complex Ant files, which are connected multiple times and the SOA framework also generates several dynamic Ant files. It took a few days to really understand all the dependencies and to finally build the whole project without any errors.
My plan was or is to migrate the whole project from Ant to Maven, since new components are planned and I would like to avoid these problems in the future and well, because it is just horrible the way it is now ;-)
Since I am new to the migration of bigger projects, I am a little bit confused about the best workflow. There are dozens of XML files and scripts involved, which are distributed in a non-Maven directory structure. Overall there are over 3000 files involved. One of the main problems is that I don't know if I really should try to migrate everything in the known Maven directory structure and therefore risk endless editing and refactoring of every single file. Or should I keep the folder structure as it is and bloat my pom.xml files and possibly run into problems with all the different involved plugins? Honestly, both ways don't sound quite constructive.
Does it even make sense to migrate a project in this dimension to Maven? Especially when the SOA framework must use its own Ant files - therefore a combination of Ant and Maven would be necessary. What would be the best strategy to simplify this process?
Thanks for all suggestions.

Here's a simple and quick answer to Mavenizing an Ant project:
DON'T DO IT!
This is not some anti-Maven screed. I use Maven, and I like Maven. It forces developers not to do stupid things. Developers are terrible at writing build scripts. They want to do things this way and not the way everyone else does. Maven makes developers setup their projects in a way that everyone can understand.
The problem is that Ant allows developers to do wild and crazy things that you have to completely redo in Maven. It's more than just the directory structure. Ant allows for multiple build artifacts. Maven only allows for one per pom.xml1. What if your Ant project produces a half dozen different jar files -- and those jar files contain many of the same classes? You'll have to create a half dozen Maven projects just for the jars, and then another half dozen for the files that are in common between the jars.
I know because I did exactly this. The head of System Architecture decided that Maven is new and good while Ant must be bad and Evil. It didn't matter that the builds worked and were well structured. No, Ant must go, and Maven is the way.
The developers didn't want to do this, so it fell to me, the CM. I spent six months rewriting everything into Maven. We had WSLD, we had Hibernate, we had various frameworks, and somehow, I had to restructure everything to get it to work in Maven. I had to spawn new projects. I had to move directories around. I had to figure out new ways of doing things, all without stopping the developers from doing massive amounts of development.
This was the inner most circle of Hell.
One of the reasons why your Ant projects are so complex probably has to do with dependency management. If you are like our current shop, some developer decided to hack together develop their own system of dependency management. After seeing this dependency management system, I now know two things developers should never write: Their own build files, and dependency management systems.
Fortunately, there is an already existing dependency management system for Ant called Ivy. The nice thing about Ivy is that it works with the current Maven architecture. You can use your site's centralized Maven repository, and Ivy can deploy jars to that repository as Maven artifacts.
I created an Ivy project that automatically setup everything for the developers. It contained the necessary setup and configuration, and a few macros that could replace a few standard Ant tasks. I used svn:externals to attach this Ivy project to the main project.
Adding the project into the current build system wasn't too difficult:
I had to add in a few lines in the build.xml to integrate our ivy.dir project into the current project.
I had to define an ivy.xml file for that project.
I changed any instance of <jar and </jar> to <jar.macro and </jar.macro>. This macro did everything the standard <jar/> task did, but it also embedded the pom.xml in the jar just like Maven builds do. (Ivy has a task for converting the ivy.xml file into a pom.xml).
I Ripped out all the old dependency management crap that the other developer added. This could reduce a build.xml file by a hundred lines. I also ripped out all the stuff that did checkouts and commits, or ftp'd or scp'd stuff over. All of this stuff was for their Jenkins build system, but Jenkins can handle this without any help from the build files, thank you.
Add a few lines to integrate Ivy. The easiest way was to delete the jars in the lib directory, and then just download them via ivy.xml. All together, it might take a dozen lines of code to be added or changed in the build.xml to do this.
I got to the point where I could integrate Ivy into a project in a few hours -- if the build process itself wasn't too messed up. If I had to rewrite the build.xml from scratch, it might take me a two or three days.
Using Ivy cleaned up our Ant build process and allowed us many of the advantages we would have in Maven without having to take a complete restructuring.
By the way, the most helpful tool for this process is Beyond Compare. This allowed me to quickly verify that the new build process was compatible with the old.
Moving onto Maven Anyway...
The funny thing is that once you have integrated your Ant projects with Ivy, turning them into Maven projects isn't that difficult:
Clean up the logic in your build.xml. You might have to rewrite it from scratch, but without most of the dependency management garbage, it's not all that difficult.
Once the build.xml is cleaned up, start moving directories around until they match Maven's structure.
Change source to match the new directory structure. You may have a WAR that contains *css files in a non-standard location, and the code is hardwired to expect these files in that directory. You may have to change your Java code to match the new directory structure.
Break up Ant projects that build multiple projects into separate Ant projects that each builds a single artifact.
Add a pom.xml and delete the build.xml.
1 Yes, I know this isn't entirely true. There are Maven projects with sub-projects and super poms. But, you will never have a Maven project that builds four different unrelated jars while this is quite common in Ant.

I have done a similar migration in the past, and I had the same doubts you had; however, I went for the "keep the folder structure intact and specify the paths in the POM files" way and I noticed it wasn't as bad as I thought.
What I actually had to do was to appropriately set the <sourceDirectory> and the <outputDirectory>and maybe add some inclusion and exclusion filters, but in the end I'd say that even if Maven's way is really convention-over-configuration-ish and makes your life easier if you follow its directives on where to place files, it doesn't really make it much harder if you don't.
Besides, something that really helped me when migrating was the possibility to divide the Maven project in modules, which I initially used to replicate the Ant structure (i.e. I had one Maven module for each build.xml file) making the first stage of the migration simpler, and then I changed the module aggregation to make it more meaningful and more Maven-like.
Not sure if this does actually make any sense to you, since I didn't have any generated Ant files which I recon may be the biggest issue for you, but I would definitely follow this road again instead of refactoring and moving files everywhere to Mavenize my project structure.

Build multiple java projects with dynamic dependencies

I have multiple java projects in a folder. Also there is a second folder with libraries, that might be used as build dependencies from the projects. The projects may also have dependencies to other Projects. What's the best approach to build all projects ?
In other words I want to build the projects without explicit telling their dependencies.I think the biggest problem is the dependecy between the projects.

There are multiple build systems that are available that you may use. Maven has a complete dependency system built into it. Almost all third party open source jars are directly accessible via the World Wide Maven repository system. Basically, you describe the jar you need (groupId, artifactId, and version) and Maven will automatically fetch it for you. Not only that, but Maven also will build your project without having to create a build file. Instead, you have to describe your project in a project object model (a pom.xml file) and Maven will download everything you need, including all compilers, etc.
Almost all new projects use Maven, but Maven has a few downsides:
Since you don't control a build process, it can sometimes feel like poking a prodding a black box to get the build to work the way you want.
Documentation can be scant -- especially if you're moving beyond basic Java compiles.
You usually have to arrange your project in a specific layout. For example, source files should go under src/main/java while JUnit tests are under src/test/java. You don't have to follow the recommended layout, but then you'd have to modify the pom.xml file this way and that to get your build to work. That defeats the whole purpose of the pom.xml in the first place.
If you already have another build system setup (like Ant), you lose everything. There's no easy way to move from Ant to Maven.
The other is called Ant with Ivy. Ivy uses Ant for building, but can access Maven's world wide repository system for third party dependencies. It's a great compromise if you already are heavily invested in Ant. I also find Ant with Ivy to be better documented than Maven (although that's not too difficult). There's an excellent chapter going over the basics of Ivy in Manning Publication's Ant in Action.
With either process, I would recommend that you build a company wide Maven repository using either Nexus or Artifactory. This way, any proprietary third party jars (like Oracle jars) can also be stored in your company wide Maven repository since they won't be in the standard World Wide Maven repository.
By the way, if this is a company wide effort, and you are moving multiple Ant projects into Ivy, I have an Ivy project I use in Github that makes things easier.
Oh, there's a third possibility called Gradle which I know nothing about. I also believe it can use the World Wide Maven repository. It's based on Groovy which is based on Java syntax, and that's about all I can say. Maybe others can fill you in on the details. The Gradle group contends it solves a lot of problems of both Ant/Ivy and Maven.

Whatever tool you use, if you have various projects interdependent, you need to be clear on the independent ones which will be built first before building the dependent projects. You need to have a clear dependency structure for your projects.

You can do this with Apache Ivy. You can lay out the locations for you common libraries, define published artifacts and inter-dependencies in an ivy.xml document in each project, and let a top-level Ant build with the Ivy tasks figure out what the build order should be based on those dependencies.