We Keep Coding

What's the best way to use GIT in our work environment? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We currently do not use any kind of version control software. We recently started using Eclipse, and our source code is maintained on a network drive. An Eclipse project was created and everyone has imported the project into Eclipse on their machines. Due to the way we are set up, we are always getting stuck in clean/build loops throughout the day which is hurting productivity.
We would like to start using some kind of VCS (most likely GIT). I am envisioning a centralized workflow with each developer having a local copy of the code on his/her machine. We would rather use GitHub Enterprise for the shared repository instead of hosting the code on GitHub.
I am not quite sure where to start in getting this setup correctly. I have been watching videos and reading tutorials, however none seem to directly apply to how we would like to do things. Is GIT the right software to use for the type of setup we desire? Also, how does clean/building work with Eclipse and the local copies vs the shared repository?

First, watch this video.
Second, if you're using Eclipse, you're gonna wanna use EGit. Very detailed tutorial here.
Third, don't throw yourself at GIT. Take SVN into consideration at some point (after documenting on GIT). Maybe a Central Version Control System will do you better than a Distributed Version Control System.
Edit:
Oh and by the way... there's a veeeeeeery long and famous Q&A right here regarding this topic. Best of luck.
Second edit:
As for SVN, here you have an easy tutorial on Subversive, and here you can find the full in-your-face Subversive documentation.

You have your needs now but your needs will change. Save yourself the headache of later moving to Git from SVN and start with Git. Here are the reasons to go with Git over Subversion:
Speed - Git is WAY faster
Disk space - Git history is small. Most of the time it takes up 1/10th the space of SVN history.
No server - DVCS allows no admin and you can skip a centralized server altogether. Your central repository can just be files on a network share.
Integrity - data corruption very easy to detect and correct.
Snapshot history - the whole project is snapshotted for each version. No mixing and matching paths with versions.
Open Source dependencies - most of the projects you may want to use are on Github. You can easily just add a submodule and version that dependency.
Power:
git bisect - find a where a bug was introduced quickly
rerere - reuse how you fixed conflicts if they come up again
supports any workflow
proper 3-way merges - this will save a ton of headaches in the future
rebasing - you can keep your history linear, even after someone merged
My last point is very important. You are just now starting to use source control. Start with the best option. You are at a point where you know the least about your needs. Things you think you don't need right now you will need later - guaranteed.

I would create a git repository on the shared drive, you don't need a server like github at all. After setting it up developers can clone from the shared drive to their local computer and push the changes back when they are done.
Every developer will end up with a local copy of the code where they have their own build environment and never be in each others way anymore.
Start with a sample project with just some files in it and play around with it, since you will need to get some experience with a version control system. Also learn the git command line tools (for windows use msysgit), because most of the examples on the internet are writen for those. For more information on git be sure to read the free git book: http://git-scm.com/book
Also see this question about using git on a windows share: How to git clone a repo in windows from other pc within the LAN?

EGIT for eclipse is the good one to integrate git in your eclipse project environment.
Besides, if you are on windows, you can download the Github for Windows, it's really simple, effective to use.

GIT is certainly the preferred way and nicely integrates with Eclipse IDE. But you could also use Subversion as all you want to have is a local copy of code on user machine(call it subversion branch). I say preferred way because GIT is way too flexible: Offline commits, full copy of body of code versus just branch etc....list is too long.
As you mentioned, you can also use github. Roughly, steps are as follows:
Just signup for it
create a repository.
Get the link to repository and Point it as new git repository in Eclipse
Push your code. Commit it.
You will have your code files in github. This will work provided you have Git installed in Eclipse. I believe Eclipse Juno already is setup with EGit (plugin for Git)
For resolving the build issues, you can use set up some Continuous Integration tools like Jenkins. This can be setup as Eclipse plugin as well.

As some already noted, for question
the best way to use GIT?
in your situation (zero SCM-experience) best and fair unbiased answer will be
Do not use Git at all!
Contrary to "Why is Git better than Subversion?" topic you can also read (some subset as result of fast-recall)
GIT - What gotchas should newcomers to version control be aware of?
What does SVN do better than git?
What are pre-requisites for learning & understanding Git?
and check other topics under git tag with multiple laments of Git-boys.
While Subversion is rather good choice (with some edge corners anyway: you may fall into "Merge Hell" even if you think about development as linear: some branches may and have to happen, into "Refactoring Nightmare" with famous "Tree conflict" error...) you can think about "Usable as Subversion and powerful more than Git" alternatives (even you'll use only small needed part or overall power): - Mercurial "DVCS with a human face, made by software engineers for software engineers, not for fashionable dudes".
MercurialEclipse is answer for Eclipse request (in Aragost recommendation Mercurial users trust)
TortoiseHG is user-friendly cross-platform GUI for all and any Mercurial needs outside Eclipse
Mercurial server require a lot less headache (notably "under Windows"), than equivalent Git-server
Mercurial real experts can be easy found (while Git-boys is more fun-club of rapturous teenagers)

Java build system with automatic dependency resolution

I am trying to get up to speed with Java after spending my last couple of years with Python and Perl. And boy is this hard! First of all, there's no easy to use build system that can do only what you want it to do without adding tons of boilerplate. Then, how to add dependencies to your project, how do you run junit tests from the build systems (say ant for example)? How can I make the build system download the dependencies on the fly (or can't I?)
Can I find some docs around that can get me up to speed with this without reading a couple of books ? I am trying to be "agile", but the comeback is hard.
Please feel free to close it if it is too subjective. Thanks!

This question is close to textbook trolling... anyway.
There are a lot of build systems that resolve dependencies for you out there (maven, ant, buildr, etc).
I'd say go with buildr since you are familiar with scripting languages.
NOTE
Though many people pointed out maven, considering your background (perl, python, etc) that will make you hate java even more (it's a sea of <XML> out there dude!). Please consider buildr if you feel frustrated enough

You don't mention which build systems you've tried (other than ant). I feel either Maven or Gradle would meet your needs (although I think Maven might fail your "tons of boilerplate" test; it certainly fails mine).

There are an awful lot of questions here. "Maven" is the Java build system that automatically downloads dependencies; it is based on Ant, which does everything else you ask about (running tests, etc).
If you want to use Maven, get started by using Maven's quickstart docs and examples.

Downloading Eclipse's Source Code [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm doing a study on large Java projects and would like to view the source code for Eclipse. I have gone to this url (http://wiki.eclipse.org/index.php/CVS_Howto) and figured that the most useful cvs repository for me to look at would be this one:
:pserver:anonymous#dev.eclipse.org:/cvsroot/eclipse (The Eclipse platform project)
However, when looking at this repository, it has so many modules! Which modules should I be trying to check out? I don't necessarily want to build the IDE from source, however, I just want to get the core Eclipse code base to perform some analysis. Would I just check out any modules starting with "org.eclipse..."? Should I be checking out any of the others?
Or is there an easier way to get the source? I read somewhere that you can get the source from the binary version of Eclipse but I am unsure where to find the source.

Just download the source tarball eclipse-cvs.tgz from here
EDIT: This also includes version history, so it may be larger than you need. For just a current version download Platform-SDK.3.5.2 ~ 100MB
It includes the sources in jar files e.g.
org.eclipse.ui.workbench_3.5.2.M20100113-0800.jar
org.eclipse.ui.workbench.source_3.5.2.M20100113-0800.jar

For empirical studies, a good resource to check out is the Qualitas Corpus. It's a collection of open-source Java programs for use in empirical studies. In addition to having source code for a larger number of major projects (including Eclipse) they have multiple versions of each program, so you can track how code changes over time, if that's important. It's a respected corpus in the Software Engineering/Programming Languages research community, and so it may make your work more suitable for comparison in the future.
I'm not a part of their project, but I have used their corpus in a recent study. If you shoot them an email and tell them what your project is about, they'll give you http download access.

I can only answer this bit:
Or is there an easier way to get the
source? I read somewhere that you can
get the source from the binary version
of Eclipse but I am unsure where to
find the source.
In eclipse/plugins/, the jars named *.source_*.jar contain source. For example, in my install:
org.eclipse.osgi_3.4.0.v20080605-1900.jar
org.eclipse.osgi.source_3.4.0.v20080605-1900.jar
The first jar contains the OSGi runtime, and the latter contains the corresponding source.

What do you use for a complex build process? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am trying to revamp our build process, which is currently a gigantic Ant build.xml that calls into other ant build files and executes several Java classes to perform more complex logic that would be impossible/scary to attemp in Ant.
Background:
experience in Java and Ant, some Groovy
Windows platforms
Goals:
run as a combination of command line cron and when a servlet is posted to
as simplified as possible, fewest languages and bouncing between techs
I need higher level logical power that a language like Java provides and Ant is pretty easy and we use the filtering to override default properties files for different clients. Mostly I'm wondering if there is something other than Ant/Java that people use.

Except the Ant you mentioned and the scarry make/autotools, the mainstream tools are:
SCons
Jam
CMake
Maven
I use SCons, because it is python based, well-funded and elegant.
Jam seems to be the most pragmatic one.
I don't know too much about CMake.
Maven may be the choice for you as it is Java centric and more high level than Ant.
More you can find at wikipedia: List of built tools

If you pursue Maven, then you will have two problems: a complex build and learning the f#*#ing "magic" of Maven. Maven just makes the problem worse because it is obtuse and overly-complicated.
I inherited a legacy Maven 1.x build at a large Fortune 500 company. I used Maven 2.x by choice on many other projects in recent years. I evaluated Maestro, in hopes that it might make Maven tractable. My conclusion, like many other peoples' (check the 'net), is that Maven is a big step in the wrong direction. It definitely is not an improvement over Ant.
I have used Ant for MANY years, including writing a large open-source library of Ant helper scripts. I have also extensively used its .NET cousin nAnt. However, Ant has two major failings. One, XML is simply not the right place to be doing build tasks. Two, Ant and XML do not scale well to large, complex builds. In fact, I have written a lot here at SO about my experiences in that arena (and with Maven).
Industry leaders have concluded that a build is just another application, and should be approached using general application tools. However, since it involves system-level and cross-platform functionality, most development languages/platforms are not properly suited (which includes Java, and therefore Ant and Maven). That also excludes .NET.
I spent two years looking for an alternative, and I found it: Python. It has the right combination of system-level access, cross-platform portability, simplicity, readability, power, robustness, and maturity. SCons, buildbot, setuptools/easyinstall, and base Python are my current target platform for the build process. When necessary, integration with Ant, Maven, and any other such tool is easy. Meanwhile, I can use these tools for the core of any build on any platform with any source language. No more roadblocks, no more crazy complexity, no more supposedly-helpful "declarative" scripting, no more black-box f#*#ing "magic".
If you can't switch to Python, then try Ant + Ivy (at apache.org). It gives you Maven's cool repository without most of Maven's evils. That is what I am doing as well, where necessary and suitable.
Best wishes.

Also take a look at
Gant
Gradle
While more general purpose build systems like SCons are very powerful, the Java support is somewhat limited in comparison to systems specially tailored to build Java projects.

I like using Rake as you can fall back on the power of the whole Ruby language and it's framework library when needed.

I use Ant, taking advantage of its macro feature. If you layout your project in a consistent mannner, you can eliminate a lot of the duplication by writing macros.
I've been building up an Antlib containing macros and custom tasks that I reuse across multiple projects.
Alternatively, some people swear by Maven. Other people just swear about Maven.

I use Maven, not just for build, I also use their release/dist plugin.
In a pair of commands I can have code that was in a source control to build, package and release.
The release plugin handles updating the version numbers, dist handles how to put everything together and zip it.
Ant looks hard when compared to Maven. Sure there is a learning curve with Maven, but reading a pom.xml is far easier than reading a build.xml.
Maven needs to be far less verbose.

I like Ant but only if you spend the time to write your own Java plugins to encapsulate complex actions. It isn't hard but unfortunately most people try to write their logic in XML w/the ant-contrib stuff. I think this is a huge mistake.
I've heard good things about rake and the groovy tools (mentioned in another comment) but I've got no experience with them.
If you're trying to script together several steps in a life-cycle you might be better off using a process automation based build server like AnthillPro (Cruise, BuildForge and Electric-Commander are the others in this space).
Another place to ask this kind of question is the CITCON mailing list. CITCON is a conference on Continuous Integration and Testing and the associated mailing list has turned into a really great community around these kinds of topics.
(I'm an organizer for CITCON but a labor of love not a profit maker. It really does have a really helpful mailing list. If I was pimping something for money it would be The CI Guys. ;-) )

Stick with Ant since you're building Java. I've mixed Ant/SCons for some JNI work, but in general I'd stay with Ant especially since you've got an existing build setup in Ant. Porting to Maven will be like shoving a square peg through a wall with no holes.
Embrace your custom Java logic for any and consider writing proper Ant tasks instead of executing external Java code. I solved some very complex parts of our build process by simply extending Ant to do exactly what I needed, ex. managing icon resources for a large gui project or injected subversion information directly info jar manifests (thank you SVNKit)

I'd go with Ant any day of the week.
It's not perfect; XML is very verbose and implementing any logic at all is almost impossible, but even the most junior engineer on the team can at least understand what the ant file is doing within a day.
Complex logic can be refactored using java and integrated in ant, if you so wish. Ant gives you all the power of java:)
Dependency resolution is difficult no matter what system you use. With ant, the best solutions seem to be either a lib directory in which all your jars are stored, or an internal web server from which the libraries are copied at build time.
I also have some experience with both Maven 1 and Maven 2. That experience left me with the feeling that Maven is awesome for hobby projects, but can have complications for software you need to maintain over time.
I see two important problems with Maven:
Any dependency you import using Maven may change over time without you knowing it, resulting in weird problems.
You import the licenses of not only the software you import directly using Maven, but also the licenses used by the libraries which are indirectly imported
In short, I dislike the fact that the build depends on the time it is started. That can be a true problem when producing a bugfix release a year after the production release.
These problems can of course be managed (maybe using a nexus proxy) but you need to consider them before rebuilding the build system. At my company we decided to use Ant for all new project and try to port maven 1 and 2 to ant whenever the occasion presents itself. It's just too difficult to keep it working.
My advice, if you and your team know how to deal with ant, try to refactor your ant file and don't jump on some other build tool. It just takes too much time to get it right; time you could spend making money and surviving as a company :)

I use Rake everywhere I can. Where you need to build java code you might use it with jruby, or look at something like: buildr

We use luntbuild. It's a web app that's very easy to use. It will check out from CVS/SVN, automatically increment the version/build number, execute build tasks in ant scripts and tag your repository with the new version. Can schedule automatic builds, have it email you or contact you via IM, also has security and build dependencies.
We're still using version 1.2.3 but I see it's up to 1.6.0. It just works.
http://luntbuild.javaforge.com/
EDIT: Re-reading your question I see now that you're looking for something to replace Ant. In our case Ant is not really a problem. We have projects setup in Netbeans, which uses Ant for building and we just have to implement some hooks into the existing scripts provided by Netbeans which is very easy to do.
EDIT: Looks like you can call Ant from Groovy. That would be nice because then you can re-use all the tasks that already exist for Ant.
http://groovy.codehaus.org/Using+Ant+from+Groovy

Try FinalBuilder
It provides a GUI interface to whatever your build process may be and has a native action for almost everything, plus an action studio where you can create your own.
With a bit of planning can be very streamlined.

I have to add to these one solution that I find I can't live without ... its called Hudson. It only takes a few seconds to setup and you can usually get away with most of whatever your existing ANT files are already doing.
Additionally, Hudson provides a great way to "cron" builds, execute test cases, and generate "artifacts" (e.g. build products) in a way that anyone can download.
It is hard to capture all that it can do for you ... so just try it out ... you will no be disappointed.

Maven is really good choice to do large builds...in the majority of the cases where it doesn't work is very simple. The people misunderstand the concepts of Maven. If your are working with the "maven way" you will end up with smaller modules which gives you a better architecture in your software. On the other hand things like Hudson will support you in reducing build times by using Maven, cause Hudson supports to build only changed modules which is not supported by any other build tool. The problem with Maven is to learn and understand the concepts of Maven for example the structure of a project(folders etc.) or only a single artifact etc. The build-cycle will support you in different areas: compiling, packaging, deployment and release which is not supported by other tools (only if you implement it by hand...I've wrote many large Ant scripts to reach this)...Other problem like changes over the time are caused by ignoring the best practice and pin pointing versions which are used.

I use mainly Ant, but Maven is also a good tool. With ant you can do anything you want.
At our company, we created a general purpose ant builder that does a lot of things: Build, Compess images, minify, generate documentation, pack files.. It is open source and we are open to improvements. You can get it here:
https://github.com/edertone/TurboBuilder

Is Ant still the best choice for a Java build tool? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
From my small amount of experience, I've only used Ant as a build tool. Are there any other projects which are better, and why?

Maven
It is much better than ant because for most common tasks you don't have to write a complicated build.xml, maven has very good defaults and it's all convention over configuration.
It has also a big central repository of libraries and it's very easy to configure it to, like, "use latest stable commons-whatever". Maven will then download the latest stable version for you (no more checking in jars into VCS) and if a new upstream stable version is released, it will download it as well. Of course, it's just as easy to lock it to some specific version should you need that.
It is also well integrated both with Netbeans and Eclipse (m2eclipse plugin) so the IDE honors whatever settings (including dependencies) you declare in the pom.xml file.
There are also some downsides to maven: some plugins are rather poorly documented, integration with both IDEs is not really perfect, and that in different ways, some error messages may be hard to understand.

Ant is still a major player. In my experience, it is dominant. Plus, with Ivy, it handles some of Maven's strengths. IMO, Ant will become a framework for other tools: XML is too rigid (see link below).
Maven 2 is also a major player. I know people who quite like it and bristle at criticisms that were true for Maven 1 (it has come a long way).
Groovy is offering some cool stuff in the build space, because they build on Ant. Gant is used in Grails, but may be subsumed into Gradle. These can be used for Java as well.
At the risk of pimping my own blog, here is a post about Gant and Gradle. Here is a link to the very current debate about their future.

in the enterprise, ant is still the entrenches player. dependencies don't change fast. unlike open source projects that keep moving to fairly newest version of dependent jars, MOST enterprises try NOT to change their dependencies too fast. Given that, maven's advantages are NOT too much compared to ant.
Then again, if you want some of maven's features, ant folks have ivy (http://ant.apache.org/ivy/) for the dependencies feature.
IF you want to continue using ant, get hold of "ANT IN ACTION", 2nd edition so that you can use ant to the best productivity.
Good luck,

Some people like Ivy, which is a dependency managing thingy for Ant so I suppose that people coming from an Ant background will like it.
Others like Buildr. It's a JRuby thing, so if you can juggle Ruby and Java in the same projects, then I suppose it'll be interesting.
Personally, I just use Maven. It's easy to whip up a default pom.xml file and have all the build commands at your disposal. And when the project grows, you already have the infrastructure in place for running plugins and adding dependencies.

You also have Gant. Gant is Groovy + Ant, you can write your tasks in plain groovy and you can also call any ant task. If you are a Java shop and want to reuse the ant skills you have but dislike XML, I recommend Gant, it is ver easy to setup and you can embed it in ant (and also call gant from ant).

I really like SCons, which is a build tool whose configuration files are all just Python scripts. This will appeal to anyone who knows Python or similar scripting languages. SCons is designed to work well with Java as well as C/C++ and other languages, and I've been very satisfied with it in the past.
Because SCons files are written in Python, you can write arbitrary Python code if you find yourself needing to do anything special. However, if you're completely unfamiliar with Python, then there will possibly be a higher learning curve than trying to extend Ant or something similar to do what you want.

Maven2 seems to be the up and coming thing.
For our projects however we are migrating back to ant wherever feasible.
Maven2 requires quite a bit of knowledge to get it exactly the way you want, and Maven2 versions seem to handle classpaths differently.
And it is a pain to check all licenses included in the dependencies of the dependencies which may get drawn in.
And may have a slower start-up time, as you need to figure out the dependencies yourself, but at least it's easily readable. No magic going on here :)
If you do use maven, give a thought to an internal repository like Nexus. That way your software is not dead if some libraries decide to go away from the net*.
*We got burned with maven1; the ibiblio maven1 repository redirects and maven1 does not support redirects :(

I would urge you to start with your requirements when considering the right tool. Each project is different, the tool you use should reflect the problem space not the fashion.
That being said, I think for general use ant is still probably the best general tool for building java applications. It is often used effectively with other tools for dependency management but there we go again skirting off into a solution without a problem.
The very good news, is that if your process are good switching build tools is a fairly painless process - lesson - start with a good process scaled to the problem at hand.

You will find already some answers in What are some good java make utilities?.