Develop Reference

Java dependancy management from a personal dependancy storage/maintenance destination

I have seen many interesting (and duplicated) questions here about "sharing or using classes between projects".
I see this as quite practical but the proposed solutions I have read about definitely assume certain prerequisites such as:
shared eclipse workspaces
projects that can be made as dependencies of oneanother
common servers such that classpaths can be added with local urls
While likely acceptable solutions, I am looking for an alternative with perhaps greater flexibility and portability.
I am thinking of learning how to use gradle (or maybe maven, I haven't fully committed to one or the other yet). And from what I understand it may be possible to manage shared classes with one of these dedicated dependency management programs.
Theoretically is this possible? Can I setup a gradle or maven enabled java project to handle and keep uptodate personal classes on a local server or folder on a portable drive or cloud mirror?
The way I understand dependency management at the moment (on a superficial level, I know the devil is in the details) is that for a configured dependency management enabled project, gradle/maven will handle classpath additions and the actual version specific comparison, retrieval and storage (and maybe even compilation is possible but I don't know about this) of JARS from external sources.
Rather than go through the steps to setup classpaths to jars I have to keep current and compiled myself as proposed in many other answers, I am considering creating a dummy project on a server that I can put generic classes which I could then point numerous individual gradle/maven enabled java projects to use. (I think most people would be able to keep them as stand alone classes, but I think I might need to keep them in a dummy project to be developed and debugged in context from a main class. I am somewhat new to java architecture so if the only thing that would make this solution impossible is pointing to a "project" instead of a "library" I can definitely adjust from there. (Assuming I am even applying the concept of the "library appropriately).)
Other info:
I would like this to simplify personal dependency using both Netbeans and eclipse IDE's and work cross platform (but Linux and Windows is what I plan to test it on)

So you're looking for portability, and you don't want to compile your java class that you want to share between projects. And you don't mind a local deployment.
The first thing that comes to mind for me is Git - I'm not sure if Gradle/Maven deal in the gritty underworld of the uncompiled. Composer will pull in git repos for php, so that got me thinking.
If you're happy with one-way sharing of code among projects, Git has submodules that let you do that.
But searching around, apparently there's a git script that goes one step further - Git Subtrees. I also found an intriguing tutorial that will allow you to make changes to common code that you change while working on any particular project that shares it - so obviously be careful - but check it out and see if the Subtrees script might suit your needs.

Actually, I don't see too much sense for dependency management on a "class level". Typically you would bundle your classes in a jar file, which in turn can be considered as a unit with a particular functional range. Such a jar is suitable to be put in a dependency management.
If you are new to such tools, I'd recommend Maven. It is widely used in the Java world and well-integrated in common IDEs. If you stick to its conventions, it will take care of your whole build process from compiling, testing to packaging. There are a lot of plugins available that let you customize practically everything in a simple XML based configuration. You'll have your first project running in 30min and your current project migrated in another 30min.
To share your code with others, you still need a repository where you can upload your Maven-built artifacts to. Depending on your preference there are many possibilities. Shove it to Amazon S3, Maven Central or install your own Sonatype Nexus in your private network.

Can Intellij IDEA exist in a Netbeans Shop?

All my other colleagues use Netbeans, but I have an opportunity to use IDEA. Will we be able to work on the same Java EE projects together, or will we have issues with projects, checking in and out of SVN, etc?
We primarily develop EE and Spring MVC applications using Glassfish on our desktops, and commit to an SVN, although it is possible that I may have to load a coworker's entire projec.

As long as you are using some standard, IDE-agnostic build tool like maven, I see no problems. I work on IntelliJ IDEA while my colleagues use Eclipse - no issues except different formatting rules or import order - all of this can be customized.
Subversion (or any other VCS) is the least of your problems. Even if the rest of your team pushes Netbeans project metadata files, IntelliJ will simply ignore them.

If you use Maven as your build tool, then yes (and Eclipse too).
All three have tooling allowing them to work well with Maven projects.
If you are using "plain" Netbeans projects I do not think that IDEA can work with them. If so, I suggest you lobby for the change. Maven is one of the investments that pay well of.

Why would you want to fly in the face of convention and be the only one on a different IDE? You'll waste time on issues that nobody else has, have formatting hiccups, struggle with pair programming etc.
As much as I like freedom of choice, the development environment within teams should be consistent.

I thought build tools like ant, maven or gradle are de-facto standart of java ee industry. Purpose your teammates to use it.

You will have issues with sharing projects, because the project folder and structure for Netbeans and IDEA is different.
However, you can attempt to share your src folders with one another and update your codes with one another through SVN, though I wouldn't advise it for compatibility reasons because you won't be able to properly share libraries and use other team functionality available in NetBeans.
So it won't be a good idea to use a different IDE so you don't waste time debugging compatibility.
Also, its useful to note that IDEA uses its own custom libraries for certain functionalities, and also build projects in a different way from NetBeans, so projects that appear to work on IDEA may not work on NetBeans and vice versa.
Bottom line, don't waste your time using a different IDE from the rest.

TFS for Java - bad idea?

We're considering TFS for our .NET based projects and as a task management platform.
Some teams develop exclusively in Java and they're quite happy with SVN (Subclipse).
Our managers came up with the following questions:
Should we migrate the Java teams to TFS as well?
Does TFS (source control only) handles well Java projects?
Is it a pain to migrate our Java code base and history from Subclipse to TFS?
Currently we are looking to use TFS as a sole source control platform for maintainability reasons. We would like to avoid having our IT guys supporting multiple systems.
Thanks

Full disclosure, I work on the team that write the Java tooling for TFS so take this answer as appropriately biased :-)
As far as TFS is concerned - all code is created equal. It's just bytes in files that it checks in to version control. Like all SCM systems it doesn't care what language the files are written in.
Microsoft provide a full, rich TFS Plug-in for Eclipse (called Team Explorer Everywhere). This provides full source control, work item tracking, build, sharepoint, reports access etc into TFS from Eclipse based IDE's. It's written in 100% Java and talks directly to the web services exposed by TFS.
In addition we also provide a cross-platform command line client for TFS so that you can talk to TFS from the command line on your operating system of choice (Mac, Linux, Solaris, HP-UX, Aix etc all fully supported).
Finally, if you have tools written in Java that want to talk to TFS then they can make use of the TFS SDK for Java which is the full API that we used to create the Eclipse integration and cross-platform command line client but packaged up with samples and snippets and ready for you to redistribute with your applications.
When it comes to build you have a couple of choices. If you want to stick with your current build server then it is likely that this already supports talking to TFS (all the popular open source build servers do). In addition to that, Microsoft provide the TFS Build Extensions which allow you to run Ant or Maven based builds on the Team Foundation Build server. The build results (along with any warnings or errors) are published back into TFS along with any JUnit test data if you execute JUnit tests as part of your build. Also you get to create and manage the build definitions in the Eclipse IDE and have one place to manage access to them etc.
So - the level of support for Java is very high and Microsoft has shown consistent investment in this area. We recently shipped some TFS 2010 Power Tools for Eclipse and we've also been shipping preview releases of Team Explorer Everywhere 11 alongside Team Foundation Server 11 (we're the same team inside the company).
To import history from SVN, that's the same as importing history from any SCM tool into TFS (or TFS into any SCM tool). You have a couple of options. You can take a snapshot and cut over at a particular point (such as a release) or you can migrate history. To Migrate history from SVN there are some partner solutions available including one from Timely Migration that I've seen a lot of customers have success with.
Hope that helps.

After a year of working on a Java/JVM project using TFS, I would like to dissuade anyone from doing this. While TFS may be considered top-of-the-line for .NET developers, you won't find any Java Developers with any experience with it. There is the plug-in for Eclipse and a port to IntelliJ, but I've had terrible luck with both, though I'm guessing it's mainly because TFS does not work like any other VCS I've used.
On our team, we've estimated a 10-15% overhead due to TFS and complications caused by it. Days of work lost because TFS decided to overwrite files, days of troubleshooting issues caused by incomplete TFS Updates. We have done a branch in 6 months because the entire team lost two days the last time we did. It's common to hear the phrase "I just updated with your latest changes, can you come check to make sure nothing disappeared in the merge?". Instead of using Jira, we're stuck using the terrible issue-tracking in TFS, causing more yet more issues.
Several of the developers on the team have taken to either using git, either standalone or the git-tfs bridge. Others just copy the source tree prior to any 'risky' activities, like updating or checking in.
Either way, I wouldn't recommend it for a team that does not have experience with it...

I like the answer of #Martin_Woodward a lot, but it is too much biased in my opinion, so I add my 2 cents here. We in our company are in a similar situation, and the decision (in my opinion) depends on the context. I can see 3 different situations, and the decisions may be different in each one:
You are mostly developing .NET solutions, and the Java parts are integrated in the .NET solutions.
Your .NET solutions are independent developed from the Java solutions, and they are half .NET, half Java.
Most of your solutions are developed with Java, and only a small percentage is developed with .NET
I would agree with Martin only in the first case. You will gain profit from the common development environment, source code control, build process ... Your Java guys will learn the differences to TFS Source Control (does it have a name??). And your future will look bright ;-)
If your .NET solutions and Java solutions are independent from each other, the only argument to use TFS for developing Java solutions is cost in operation. And you should carefully look at it, if the savings for operating the development environment only TFS will out weight the additional cost of switching your Subversion projects to TFS.
In the last case, it would be an awful decision to switch with a lot of people just to have a common environment to develop. You may integrate Subversion into VisualStudio (using e.g. VisualSVN or other plugins), and you have nearly no invest at all.
The migration of source code including history is normally a pain, and it depends on the source and target if that works well. We have good experiences with CSV and SVN, but no (good) experience with others. But that is normally not a problem, you may use your old SVN repositories (read-only) and just migrate the last milestone. After some time, SVN repos may be let alone ...

After 1 year working with TFS/Java I completely agree with Dusty J (Yes, TFS/Java is bad) and completely disagree with Martin Woodward about great Microsoft support. Although for my duty as a developer the Eclipse TFS is OK, the problems are for my build/release duties.
First, this Eclipse plugin does not allow creating a branch for several projects at once as in CVS/SVN. One needs to create a branch separately for every project. Then we cannot keep the same project names in the branch – one needs changing a project name and after checking out from the branch to rename to the original name. See also my post How to associate an Eclipse Workspace with TFS workspace?, there is no way to associate an Eclipse workspace with TFS workspace. Thus, the mapping for a local folder cannot be saved; it needs to be done again after opening another Eclipse workspace for branch building. And since the local mapping is the same there is a possibility of erasing a local folder with unsaved work as Dusty J wrote.
This removing local files without warning is a terrible feature of TFS (see the post Why command get from a command line in TFS removes parallel projects?). What Microsoft thinks about the possibility of erasing local files just under regular option "Remove Local Mapping" in Eclipse?
So, despite my effort to learn TFS I still spend 10 times more time for various builds as compared to CVS I used before.

(Another biased MS employee)
TFS formed a team about 18 months ago to focus solely on making the Java experience great in TFS/Team Services and across all platforms. I am on that team and I think we have made a ton of great progress. I won't disagree that the end to end story was pretty bad when this question was asked, but I think the answer has changed quite a bit in the last year.
My team provides build and deployment tasks for TFS as well the plugins for Eclipse and IntelliJ to make the end to end experience as complete as possible. We are also working hard to make sure we document how to get the best out of TFS if you are a Java developer.
If you want more details, checkout http://java.visualstudio.com.
Thanks,
Jason Prickett

Why not use SVN for the .NET projects? Is there any reason for that? There are multiple plugins for SVN in Visual Studio as well as a windows shell extension.

Java & Flash in one project: How to organize it in Eclipse and Git?

I have a web project that contains components in different languages: two components in Java (that have to run on different servers), a component in ActionScript, and a component in C#.
I would like to have all of them in one manageable chunk. The two Java components are being developed in Eclipse and use Ant for building.
So far the Java components are separate projects in separate Git repos, the Flash and C# components are not under git, and their sources are on the local machines of their respective developers.
How can I turn them into, sort of, one entity?

I don't know if I can answer your question completely but I can add a little to the discussion. Git by nature I believe (someone correct me if I'm wrong) supports a very fine granular structure when it comes to repositories. In other words I think your best option would be to have one git Repo for the each java source, one for the ActionScript source, and the last for the C# source. The reason being that I believe the community is focused on having one repo for each project. I am only familiar with eclipse so I highly recommend EGit. For ActionScript I use FlashBuilder and the same EGit plugin. I recommend doing the same. As far as C# goes (I assume you are Using Visual Studio) Git Extensions seems to be a popular option.
Note: Egit can easily be found in the Eclipse marketplace if you have it installed.

In enterprise Java/.Net projects, does every developer have all dependencies in their classpath?

On large-scale Java/.Net Enterprise projects, does every developer need to have all the components/libraries/dependencies in their classpath/local development environment, in order to make it build?
Or are they divided up into smaller sections can be built in isolation (so that they don't need to reference all the dependencies)?
In other words: if they want to run the whole application, they need all the components; but if they are only running a subset of the app, they'll only need the corresponding subset of components.
Are large enterprise projects usually organized in the first way or the second way?
A possible organization is if you are working on a module of the whole project that is self-contained, but referenced by other modules (in other words, a leaf-node in the dependency tree).
Another organization is if you dynamically load classes that you use, you can build without having any of them in your classpath. To run it, your classpath only needs to access the ones that you actually load (there might be many others that form different parts of the project, that you don't load).
These are theoretical possibilities; but what's standard practice for enterprise projects, in... well, in practice?
I've expanded this to include .Net, because I think the same issues would arise there (DLL hell?)

There's a different answer to this question for every project out there. A few general points:
"running a subset of the app" is often not possible, as very few apps are modular enough so that each part of them can actually run independantly.
What you sometimes have is an app core that is always required, and modules built on that core that are more or less independant of each other.
The big difference is usually not between having vs. not having all components, but between having them as source code vs. having them as JAR files.
On large apps, developers typically have only the parts they're working on in source code and the rest as JAR files
If you need runtime modularization (i.e. components are loaded and unloaded on demand at runtime), that's what OSGi is intended for.

They may need only a subset to build, and another subset to run their tests, but because all dependencies of less-than-trivially-sized Java projects can very quickly become a nightmare to keep track of, Java developers have come to love developed a love/hate-relationship with their elaborate build systems, such as Maven, which manage their development environment for them.
For projects that do not use such a system, it is generally easiest to just include everything all the time. The trade-off is unnecessarily bloated development environments versus having to spend time to track down missing dependencies.

A good project structure will break down things so that you can run independent modules.
But in real life, most projects I've seen don't do this until someone gets fed up and takes initiative to break them down.
If you use a good dependency management infrastructure like Maven or Ivy properly, you can store compiled modules on a server and download these dependencies on an as-needed basis.
You can also get away with having many mock objects and services to help break down the testing dependencies on other product components.

I certainly agree with the comments that it would be "good" to separate things. But in practice, that's very rare.
Assuming that you must work in an environment which has not been separated, there's another organizational strategy, and it's what I've seen used. Since your question refers to both build and run dependencies, you don't appear to be talking about processes, but about classes and jars.
The simple solution for that is to have the complete set of built, integration-tested (or integration-test-ready, for that matter) dependencies up on a shared server.
Then developers build in their local environments the portions of the system on which they're working, using a classpath which references first their development and then the appropriate shared server.

Your question isn't very clear, but I think the answer is that every class your application needs has to be in the CLASSPATH or the class loader with throw a ClassNotFoundException.
That's true whether you're a solo developer or working on a larger, distributed team.
In my experience, applications are packaged one way. If you only want a subset, you have to package it as such.
If you mean test cases as something separate, those usually aren't packaged with production code.

In my opinion, it's not whether developers can work on a subset of the application, but rather managing the dependencies between the projects (think Eclipse projects) that make up the app. Often you might have a tree of such projects where one or more project can depend on other projects. In such cases it's usually the role of the upstream/common project to make sure downstream projects are not broken due to changes in this upstream project.
Think of it like this - let's assume you have a utils project where you put all the common/utility functionality for your application - this could be validation logic, string utilities, logging, etc. And you have a bunch of other projects that use classes from this utils.
utils
/ \
proja projb
In this case, the person working on utils should also have proja and projb on their development environment as any change to utils will break them. However if you're only working on projb then you might not have to include proja as you have no dependency to that project.