I'm working on a project that has a version checker to see if it's up to date. The way I do it is by including the version in the source code of the main class and in my Github repository, I have a file that just includes the latest version.
Whenever I push to the repository, I have to increment both the version file and field in the source. Unfortunately, I'm incredibly forgetful and always forget to increment at least one of them.
A little information, I'm working in Eclipse on a Java applet. I'm not entirely sure what you'd call it but the version file is adjacent to the src/ directory (I guess the project root). I should also note that I'm a total noob with git and have absolutely no idea what I'm doing so examples would be appreciated.
Is there anyway I can easily manage the version that will guarantee that both change?
With Git you could write a commit hook which increases that number. I would set a beginning and an end marker and have the number between them. A pre-commit-hook would increment and replace that number.
More info at the git book.
Related
I have a scratch file using guava collections, and I get some weird errors that I have to assume is due to the editor and the actual run environment assuming different versions of the guava collections:
Exception in thread "main" java.lang.IllegalAccessError: tried to access method com.google.common.collect.Range.<init>(Lcom/google/common/collect/Cut;Lcom/google/common/collect/Cut;)V from class
com.google.common.collect.Ranges
at com.google.common.collect.Ranges.create(Ranges.java:80)
at com.google.common.collect.Ranges.closedOpen(Ranges.java:114)
at Scratch.main(scratch_2.java:69)
Not that I can actually know that for sure because I also can't figure out how I'm supposed to see which version the scratch file is pulling in. I've removed guava from my project's deps ENTIRELY and the scratch file still works... WHY? Where is the library coming from??? The scratch run config is completely empty of anything that would dictate this:
And yet it still runs just fine. I discovered that if I delete the guava entries from my local ivy cache, it won't run anymore. If I then add guava back to my project's deps, it ends up in my ivy cache again, and then even if I remove guava from the project deps the scratch file is fine again. So does the scratch file just pick a random version or something? The ivy cache, which is at ~/.ivy2/cache/com.google.guava, looks like this:
But there's also that "jars" folder that has a guava-12.0 for some reason:
And again, I have no idea which version is being used, or why the cache has so many different versions of it. Any ideas?
One way that proved to be the simplest to me was to select "use classpath of an existing project module" (which has dependencies configured) in the run configuration dialog. This is useful if you want to pull out a piece of functionality from your project to play with in isolation but still use the configured dependencies.
I had a similar issue in PyCharm that I just fixed - so your mileage may vary here. It terms out that there was a Python virtual environment attached as the default to the project window (I had had multiple projects open in the same window - but evidently the first one became the default).
I dug into the list of interpreters, found the one I wanted and edited its properties, specifically Associate this virtual environment with current project.
I checked that box for the virtualenv that had the libraries I was looking for and this fixed the compilation errors in the editor itself.
Is there any build tool like maven,gradle support to build only staged/committed code not to include unstaged/untracked file.
Basically while development some scenarios arise in middle I want to check what committed package vs uncommitted one.Though I can achieve two different directory but such flexibility in any build tool will help a lot.
Ex: Consider I have one maven project I modified and committed & pushed the code to GIT Repo.Later I started my further development.When I do build, it builds including all the files but I wanted to know If there is any way I can skip the unstaged/untracked files in maven pom.xml to build only committed files.Any plugin like that which helps to achieve this or any other build tools.
I think git stash comes in handy for this:
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
Something I use and find very convenient is particular Source Code Management plugin for Jenkins, see complete list of similar here. In my case I use Git plugin, which provides Refspec configuration property. I put there either committed or uncommitted changes' refspec. The build uses source code built until the change pointed in the refspec. Due to my understanding - this is exactly what you need.
P.S. I also build with maven, even though this doesn't matter for this case.
We use gradle to build our Java projects, some are based on JDK7 and some on JDK8. I know of the org.gradle.java.home property, but it seems flawed to me.
If I configure it in '~/.gradle/gradle.properties' this will force me to use the same JDK for all my gradle projects.
If I configure it in '/my-git-project/gradle.properties' this will force me to put a reference to a local JDK installation in a shared Git repository. The path to JDK do not belong there.
What I basically would like to have is something similar to this in '~/.gradle/gradle.properties':
systemProp.jdk8=/my/local/path/to/jdk8
systemProp.jdk7=/my/local/path/to/jdk7
And under source control in '/my-git-project/gradle.properties':
org.gradle.java.home=$systemProp.jdk8
What's the best solution/workaround for this?
This is more of a process question than a Gradle or Java question. Ultimately, you have to force everyone to specify their various JAVA_HOMEs without being onerous. You have several options:
Command line: ./gradlew -Dorg.gradle.java.home=/path_to_jdk_directory
But, of course, now everyone has to type some hideous junk into their command line every time they run a build.
gradle.properties and check-in the path. Then, make everyone use the same path.
Not everyone's going to want to use the same path, especially if you have Mac/Unix and PC users.
2b. Instead of using an identical path, everyone could modify their local gradle.properties with their custom values, then never check-in their modifications.
Primary problem: someone's totally going to check-in their local values and screw up CI and everyone else.
gradle.properties.template check-in, everyone creates their own gradle.properties; put gradle.properties in your .gitignore
This might be your best bet. You have a template file that you check-in, but everyone has to copy it to gradle.properties and fill in their specific values. You'll need to setup your CI to do something similar, or check-in something like gradle.ci.properties and have CI use that. But, everyone only has to do this once instead of once per build. Unfortunately, they will have to update their personal file every time the template changes (unless you write some code to do that).
We cope with that problem like this:
The one who starts the build is responsible for properly setting JAVA_HOME
On developer machines that may be brittle. But it works perfectly, if you build and deploy from a dedicated buildserver.
I'm currently working on a Spigot plugin and have never bothered updating the version number as my plugins have always been private. However I've been wondering if there was a way that does this for me automagically.
I know it's possible using Ant but the answers I've seen so far require an external file in which the actual version is stored, and still requires manual actions.
For those not familiar with Bukkit/Spigot, a plugin.yml looks like this:
name: PluginName
author: Author
version: 1.0
main: path.to.main.Class
So I'm looking for a solution which gets the current version from the file and increments the minor version by 1 and if possible the major by 1 if minor is > 9.
Update the plugin.yml for many reasons (i have many private plugins)
Get into the habit of version-ing your work. What is there to differ your old "changes" to your new ones? Not only that but, that version number can be used through the plugin manager.
Lets say you need to get that version (or some other plugin does) in the future. The ONLY way (besides an MD5 check) to get the version of your plugin, which 9 times out of 10 is to differentiate it from another version of that same plugin.
If your adding it to a server, how do you know which version you are running? For example version 1.1 contains a new command, but version 1.0 does not. You cannot check that if the version was never changed.
You dont HAVE to change it. There is no reason to be required to, but its good to practice development with version numbers like almost all other developers.
However, to answer the automated incremental version, no. You cant modify that compiled jar (unless you get down and dirty with another plugin BEFORE your plugin is loaded). Possibly, you could make some sort of plugin to your IDE to automatically increment it? But do you see where this ends up? Just change it when you feel that you have made progress towards some feature.
Over the course of having this repo (originally SVN) I've not been to good with keeping file links together. I've changed IDE's twice, split the project into Netbeans modules, and mavenized the project over its time. Most of the file history is lost, mainly because during mavenizing I deleted the entire trunk, committed, copied over the maven project, and committed. Not exactly the best idea, as I later found out all history reset to that point. Its gotten so bad that a repository stats program is useless since it says I have 50,000 lines of code invested instead of ~8,000.
Is there any way to fix all the broken file histories? I have access to SVN and Git if Mercurial can't do it
Hrm, and the time you did your delete and copy you'd've been fine had you just done hg addremove --similarity 90 which says "remove everything that's gone, add everything that's new, and if they're 90% similar to one another count is as a rename".
Now that that opportunity has passed there's no way to move one w/o re-writing your repository, which invalidates all the clones out there in the wild as all the node ids (hashes) change. If that's okay and you have a largely linear history you can probably get by with something like this:
hg export --output "../patch-%n.patch" 0:tip # exports every changeset to a patch file
cd ..
hg init newrepo
cd newrepo
hg import --similarity 90 ../patch*
That takes a linear history from your first commit to your last (excluding branches and other heads, etc.) exports them to patches, creates a new empty repo, and imports the changesets using the rename detection feature.
This is a pretty drastic act so make sure it's really worth it to you and keep your old repo around for good measure.