I'm new to development and I'm sure this is a silly question but i can't work out how i should be backing-up copies of my project.
When everything's working right i want to save a copy/make a back-up so that if i ever mess everything up i'll have something i can go back to, but of course it's not as simple as just copying a file like i normally would for anything else. Sorry for the silly query, but if someone could point me in the right direction as to how i should go about this that would be great!
It's not a silly question. You can back up your project directory (just make a copy, zip, etc) but I would advise you to have a look at version management (cvs, subversion, git, whatever you like). With version management you can go back to any state, create different development branches etc...
When everything's working right i want
to save a copy/make a back-up so that
if i ever mess everything up i'll have
something i can go back to
A version control system is perfect for you. Eclipse allows to clone your repository into a version control system such as CVS, SVN, Mercurial, Clearcase, Git, etc.
For me, I use Mercurial (previously using SVN), and its Eclipse plugin can be found on JavaForge.
I find Mercurial to be very handy.
It requires no server, but it still allows for multiple developers on the same project by splitting the program into two different branches of development and merging them together when complete.
Even without resorting to a version management, Eclipse provides a similar feature:
in the Preferences, go to General -> Workspace -> Local History
You can export your project as an archive and just save it somewhere, then import it whenever you need/want to. Just right click on the project, choose export and follow the instructions
Version control software is usually the best option, allowing you to create branches and browse revisions easily.
If you're on Windows, you can set up a local SVN repository using VisualSVN server very quickly.
If you'd want the repository online, have a look at Google Code (only open-source) or Assembla (they mostly offer paid services, but do provide nice and free SVN or GIT repositories).
Related
I have following problem:
3 people are working on the same Java project and want to share a workspace so we can all work together. Our computers are connected to a local network, but we want to share the workspace created in one computer.
Git is currently the standard tool to use in this case. There are others but I would recommend using it over anything else. It is also free.
http://git-scm.com/
After downloading and installing on each of your machines create a public repository to store the project.
Here is the getting started page:
http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control
Multiple Eclipse instances would NOT run well on the same "physical" files. Eclipse does not even reload directories when there are modifications. This means, you get trouble if you sync the filesystems.
The best way to work together and share the code is to use some kind of revision control system, i.e:
git
SVN
Mercurial
I would look into setting up some kind of version control, like Git, and some hosting service.
To this day I always use Eclipse for my Java developing stuff but in reason of some strange window handling improvements ;-) I think about a switch to Netbeans.
Based on the fact that other office mates still use Eclise I ask myself is it simply possible to use both IDEs side by side in the same project? What are side effects?
The related projects are all Maven based.
If your project is Maven based, then there should be no need to store IDE-specific files in your version control system (VCS). Consequently, there should be no impact if you choose to develop in one IDE over another, provided they understand POM files.
Each IDE will read the POM and generate it's own local files to cache state about the project. These will be different for each IDE, but since you don't commit those to VCS it doesn't matter. I suspect even if you did commit them, the paths and filenames are likely to differ anyway.
It's plausible some of your Eclipse friends will edit the POM to satisfy the stupid, stupid, stupid m2e connector system, but that should be ignored by other IDEs.
I have a desktop at work, and a laptop at home. I do not carry my laptop to work. Is there an accepted way to use the same NetBeans Java project from both machines?
I currently store the project in a Dropbox folder and access it from both machines. It works 95% of the time, but I occasionally have little glitches (library references, filename case-sensitivity, etc).
I have used a shared network drive, but the latency when compiling and deploying from home isn't acceptable.
I guess I could commit it to SVN everyday, but I probably won't always remember.
Looking to know how others might approach this.
Source control is the best option here, You could use some free SVN/GIT service provider too for your private project
See
https://stackoverflow.com/questions/59791/free-online-private-svn-repositories
Create a bare git repository in your dropbox folder and push/pull from that at home and work. It works very well, and its not that hard to remember. The nice thing about git is that you only need shared disk, which dropbox takes care for you. You don't need a server.
I'm part of a project java and we use a netbeans plugin named Team Server. This plugin allow you to create a project in java.net and work it under Kenai infrastructure. It is really easy to use.
I am practicing java in Eclipse both in home and college.
Is there any way that when i co the coding the file save on some server and syc there and then when i go to college then again i can use same file
You should look into using a distributed version control system like mercurial on bitbucket. The advantages of mercurial and bitbucket are really easy setup and unlimited private repositories (github doesn't offer this) which is perfect for course work and you get your stuff backed up on the cloud.
You need a revision control system. Take a look at the various plugins for Eclipse, like for example git or svn plugins.
What you need here is Revision control, but you will need to install it in a server you have access from both college and home. Maybe your college can provide you with some space or you might start a personal project in google code or gitHub. :)
I find CollabNet SubVersion Edge pretty Straightforward and easy to configure.
We are currently using JDeveloper to build our production EARs. One problem with this is that if the developer doesn't add new files to a VCS, then that developer is the only one capable of making EARS, and therefore he can use unversioned files as well.
What would be a good system that seperates this, so that EAR files can be correctly produced without depending on the local developers workspace (this would also ensure that they add their files to a VCS before allowing to make a deployment/check-in).
One problem with this is that if the developer doesn't add new files to a VCS, then that developer is the only one capable of making EARS,
If the developer doesn't use the VCS, this is not your only problem:
You cannot reproduce things in another environment, you're tied to the developer machine (but you're aware of that). What if he is sick?
Not versioning files means you don't have any history of modifications and that you don't know what you put into production ("Hmm, what is in this version? Wait, let's open the EAR to check that.").
And last but not least, in case of hardware failure (e.g. a hard drive crash), you can say good bye to everything that is not in the VCS.
So, the first thing to fix is to ALWAYS version files, even if there is only one developer as working alone doesn't save you from the mentioned problems. These points should be reminded (the developer needs to be aware of them to understand their importance).
To make sure this happens, you should actually not rely on the developer machine to build the EAR but rather rely on an "external" process that would be the reference. You want to avoid this syndrome:
alt text http://img716.imageshack.us/img716/9901/worksonmymachinestarbur.png
To put such a process in place, you need to automate the build (i.e. your whole build can be run in one command) and to break the dependency with your IDE. In other words, do not use the IDE to build your EAR but rather use a tool like Maven or Ant (which are IDE agnostic). That would be the second thing to fix.
Once you'll have automated your build process, you could go one step further and run it continuously: this is called Continuous Integration (CI) and allows to get frequent, ideally immediate, feedback about changes (to avoid big bang integration problems). That would be the third thing to fix.
Given your actual toolset (which is far from ideal, there is not much community support for the tools you are using), my recommendation would be to use Ant (or Maven if you have some knowledge of it) for the build and Hudson for the continuous integration (because it's extremely easy to install and to use, and it has a Dimensions plugin).
Here's my recommendation:
Get a better IDE - IntelliJ, Eclipse, or NetBeans. Nobody uses JDeveloper
Have developers check into a central version control system like Subversion or Git.
Set up a continuous integration facility using Ant and either Cruise Control or Hudson to automate your builds.
What we do is use cruisecontrol. It does two things, it lets us do continuous integration builds, so that we have nightly builds as well as lightweight builds that get built every time a change is checked it.
We also use it to more specifically address your issue. When we want to ship, we use cruisecontrol to kick off a build, that is tagged with the proper production build version. It will grab the code from our version control system (we use SVN) and will build on that, so it is not dependent on developers local environments.
One thing you might also want to consider is creating a production branch to build out of. So, production ears for a particular release are always built from that branch. This way you have even have a bit more control over what goes into the build.
Instead of doing builds from developer workspaces, setup Maven, and have something like Hudson run your Maven build. The artificats of this build (your ear) gets deployed.