At work yesterday I committed an Java Applet Jar file to our svn project. The project manager pushed it out for me, but when it's on production the file fails. I can open the jar and the classes look fine.
Could SVN be doing this? I don't use svn, I'm just trying to figure out why it works on my dev, but comes out corrupted on production? Maybe a text/binary setting or something?
You really shouldn't be storing binaries (e.g. JARs) in Subversion. Use an artifact management tool such as Artifactory, Nexus or Archiva. You can access the artifacts via Maven, Ant/Ivy, or a variety of other tools. Releases (e.g. WARs) are just URLs given to your release manager.
SVN can corrupt a binary if incorrectly set to text, but that's unusual. I believe *.jar would default to binary, not text, unless someone is doing things by hand incorrectly.
I usually verify JAR/WAR files are ok by just copying, changing the extension to .zip, and opening them up.
I have been using svn for storing jar files for many years and deploy to production right from my svn checkout and have never had an issue.
Try to check md5 of your local copy + on production
openssl dgst /path/to/your/file
Or you have some issue with privileges? Try to omit SVN in order to deploy on production and then check whether everything is OK.
I would very much doubt it.
Have you looked at the comparative filesizes etc ensure all the file has been transferred
While SVN will not corrupt your files by design, it is not totally unthinkable that something goes wrong along the way and you end up with corrupted files.
So in general, when you encounter corrupted files you are affected by either
unexpected effects of data thanges that SVN performs by design (e.g. svn:eol-style keywords)
faulty hardware (bad harddisk?)
bugs in the operating system or its file system; see for example this description of afile corruption bug in Windows 7.
Related
I have a Maven project. After I make changes to the project, I package the project up into an Uber Jar file and upload that to my backups. I am wondering, if my computer were to break or I lose all the code to the project, can I get the project back using only the Uber Jar file or would the project be gone forever?
How can I open this Jar file as a project and view all the Java code inside of it?
It would be entirely gone; that jar file contains only class files, not your source files, and you can't 'recover' source files from class files (you can decompile them which is mostly useless for this purpose; all comments, most names, most structure - all gone. You can't feasibly continue your project with this).
As it isn't in there, it's not possible to 'open a jar file and see all java code inside it'.
You'll need to set up backups.
The proper way forward is to first set up version control; this ensures that you don't just have a backup of the latest state of your source files, but every state of it - you can travel back to any time. Protects against code you deleted by accident, and means you can freely remove code you think you no longer need without that nagging feeling of: Yeah but what if.... maybe later? - so stop commenting out stuff you don't need, just get rid of it. It also means if there's a bug, you can time travel to the exact point in time when you added the line, and you can review the changes made by others in a project (presumably you're writing this on your own for now, but at some point you'll work with more people than just yourself!)
Read up on git which is the version control system that 80%+ or so of the community uses, probably best not to spring for exotic options if you aren't familiar. There are a billion tutorials out there to find if you search the web.
Host your git on a site like github or bitbucket which therefore also takes care of backups. Alternatively, host it on your own server (it's not complicated; git is open source). If you can't do that either, just let git write to a local directory and then use e.g. backblaze or something similar to ensure that file is backed up.
Yes, you can view your code by using a decompiler. I have experience mostly with IntelliJ, and this IDE includes a decompiler of its own. In case you lose everything and have only the jar file. You can use this included decompiler to get your source back from your .class files. But instructions on doing that are a story for another question...
If you want to secure your code use GIT. A version control tool that is a must when it comes to programming. Google about it and after a few days of playing around with it, you will never worry about such things.
Right-click on your project.
Select Build Path.
Click on Configure Build Path.
Click on Libraries, select Modulepath and select Add External JARs.
Select the jar file from the required folder.
Click and Apply and Ok.
The IntelliJ 2017.2 documentation suggests including the .idea folder that contains that IDE’s own configuration files (excepting the workspace.xml and tasks.xml files). I can understand the sense in this, as I could incorrectly configure the project settings and want to revert.
Yet, I want to post this open-source multi-module Maven-driven project to BitBucket for public access. Obviously, not everybody uses IntelliJ as their IDE, so I do not want to force my IDE settings on them.
➠ How do open-source authors resolve this conundrum?
My suggestion that comes from experience is to always explicitly ignore (that is, add to .hgignore or .gitignore) IDE configuration files or directories.
It is not only a question of not spamming a project with configuration files for a specific IDE. The real problem begins when more that one person uses the same IDE. Depending on the IDE and on how it is configured, you can fall in a situation where each commit contains changes to these files, and will confuse all the other developer using the same IDE, which in turn will overwrite the changes again in a infinite loop.
Some of your IDE settings will be global and stored in your home directory. The ones that are project specific will survive as long as you don't change the local directory in which you cloned the repo. If you change directory, in my experience it is always tolerable to reconfigure the IDE. There are at least two situations when the local directory changes: (1) you remove the directory and clone the repository again (2) you use more than one computer.
If you are concerned for things like coding style, then the best approach is to use a command-line formatter tool that works for any editor or IDE. That tool will have its configuration file committed in the repo, since coding style is something that should be equal for all developers and files of a repo.
Using Eclipse I accidentally deleted the wrong folder on my file system and lost hundreds of java files on my mac yesterday.
I am using a second mac to connect to my mac via firewire.
My mac appears as an external disk on the second mac.
I am running data recovery programs on the second mac to ensure that none of the deleted files are overwritten by writes to the file system on my mac.
I've tried a couple data recovery programs (Disk Drill, Data Rescue 3), but they don't seem to be able to recognize .java files.
Has anyone had a good experience recovering deleted .java files on a mac?
Eclipse usually keeps internal history. You should be able to restore the files using Eclipse itself, if the files were deleted in Eclipse: In context menu of you project you should see "Restore from Local History.." item.
On the other hand I would recommend to always use SCM tools (such as Git, Mercural etc). This way you will never lose your code. Practially every SCM tool this days has a very good Eclipse plugin.
I was recently given some code that was worked on by someone other than myself, and after lots of work involving hunting down external dependencies, and editing the build.xml file to get ANT to build things in a sane way, I'd like to now get the code into a subversion repository.
The team I'm working on is rather small, but the members on the team change often. So I want people to be able to start working on this code as quickly as possible. A simple checkout from the repository, and opening the project in Netbeans to have everything building and executing properly would be ideal.
How do I achieve this when there are external dependencies that are not going to be on other team members machines?
Should I place the libraries my project uses in the VCS?
How do I instruct subversion to not track generated files such as class files and jar files?
Should binary resources that are unlikely to change such as images and sounds be placed in the VCS? If not what would be the best way to distribute them?
Thank you.
1) yes. Anything needed to build and deploy the application and isn't generated by the build process goes into version control (yah, I know the maven fanz don't like that).
2) make sure everything that's generated goes into distinct directories that you exclude from version control.
3) see 1). Same thing. Same with project documentation, release notes, etc. etc.
The biggest problem of course are directory names which will be set in your IDEs configuration files and differ between development machines.
Not just the location of the project directories, but the IDE itself, JDKs and other tools, appservers, can all be different between machines. It's a constant problem.
I usually use maven cause you can have a repository for jars and dependencies this makes life easier, but since you have already refactor your code to use ANT maybe this is not what you want, to use subversion with netbeans then you might want to add another folder for jars like libs or something and then another for the binaries like audio etc. Also check for the svn plugin for netbeans it will add the ignore to the dir and just update java files.
To add files to ignore you can use
svn propset svn:ignore -F .
or you can look for the config file in your subversion home and add something like this
global-ignores=*.classs
Hope this helps
what I'd like to do is have files in a central location so that when I add people to my development team they can see the base version of these files but meanwhile have the ability for the rest of the team to work with their own local version.
I know I can just put the files in source-control (we use Tortoiese-SVN) and have my team change the local versions but I'd rather not as the exclamation mark signaling the file has been changed and needs to be committed, quite frankly, irritates me greatly.
I'll give two examples of what I mean:
We use quite a few build.xml files which relate to a single properties files which contains many definitions. Some of them can be different between team-members (mainly temporary working directories) and I'd like a new team-member to have the ability to get the properties file with the base config but change it if they wish.
Have the eclipse settings file in the SVN so that when a new team-member joins they can just retrieve the files from the server and have a base system running. If they wish they will be able to change some of these settings.
Thanks,
Ittai
What I have done in the past is having the file in a different location or with a different name inside the repository with an ignore real_file rule so that the subversion will not complain on the changed file, and have a small script that will copy the files to the concrete location.
For example, the .project Eclipse project file can be named eclipse-project-default in the repository. When a user downloads the local copy they run the script and they get a fresh .project (copy of eclipse-project-default) that they can change and will not show in the subversion status command.
The problem with this approach is that it is often easy to make a change to the file that should go to the central repository and is forgotten. The approach requires changing the actual file, and applying the same change to the config file that is actually uploaded. And then commit that change.
This really is a case for version control as you point out, but having said that I guess you could put a copy in a central file server and have them download it from their. You may even want to make this a read only file or directory.
If the status indicator bugs you that much you can set this file to be ignored by your version control system.